Handle race condition between knative operator and kubernetes resources it requires

The knative operator and operator webhook require that several configmaps and secrets be present before the application is launched. If they launch without these resources, they fail immediately (<1s).

Because these processes are launched via Pebble, we might expect that Pebble would auto-restart these processes if they die. However, Pebble sees a quick exit (exit in <1s) not as a start and fail but instead as if the processes has not started at all (see [here](https://github.com/canonical/pebble#viewing-starting-and-stopping-services)), putting the process in an inactive state that cannot be easily recovered (this is discussed more [here](https://github.com/canonical/knative-operators/pull/82#discussion_r1131068706). We should handle this somehow.

Start by examining how the Knative operator and operator webhook are launched through Pebble, focusing on their dependency on the required ConfigMaps and Secrets. Review Pebble's quick-exit behavior and the linked pull-request discussion, then define a recovery path that handles startup before those Kubernetes resources exist and verify that the processes reach an active state.

Written by the indexing model from the issue text.