refactor: use main event handler and defer it if Knative CRDs are not found

[DnPlas]

The Knative Serving and Eventing charms have a strong dependency on knative-operator, as it is the application that applies the KnativeServing and KnativeEventing CRDs and has the business logic to reconcile such CRs. Because the Knative Serving and Eventing charms depend entirely on the existence of those CRDs, this commit refactors the charms logic to:

1. Use a main event handler that can be deferred in case the required CRDs are not present
2. Remove any operation for the on_install event, and use the main event handler for config_changed as it is guaranteed that it'll be triggered right after on_install

Fixes #156

Manual testing

1. Deploy knative-{serving|eventing}
2. Depending on which charm, you may need to run some configs, for example, for serving:

juju config knative-serving namespace="knative-serving"

3. Observe that in the absence of knative-operator, the charm goes to waiting status:

knative-serving/0*       waiting   idle   10.1.205.36         Waiting for knative-operator CRDs to be present.

4. Deploy the knative-operator charm

juju deploy knative-operator --channel 1.12/stable --trust

5. (optional) If you want to speed up things, you can update the hook interval

juju model-config update-status-hook-interval=5s

6. Observe that the message goes away and the error is not present any more

knative-operator/0*      active    idle   10.1.205.35
knative-serving/0*       active    idle   10.1.205.36

[mvlassis]

Minor comments, great work as always!