Use a resource processor for ingresses and ingress classes

[impl]

Description

This change moves the handlers for the ingress classes and ingresses in the fetcher to their own resource processors. Because of the strange interdependence of the Ambassador service, which must be discovered, ingress classes, and ingresses, we also introduce a dependency handling mechanism that (a) makes it clear where that information is coming from and (b) automatically generates the desired handling order for data coming in from watt.

Related Issues

• Regression: Ambassador fails to start if there is an IngressClass resource in the cluster #3142

Testing

New tests were added, and this change was tested against the current integration tests in K3d as well.

Tasks That Must Be Done

• Did you update CHANGELOG.md?
  • Is this a new feature?
  • Are there any non-backward-compatible changes?
  • Did the envoy version change?
  • Are there any deprecations?
  • Will the changes impact how ambassador performs at scale?
    • Might an existing production deployment need to change:
      • memory limits?
      • cpu limits?
      • replica counts?
    • Does the change impact data-plane latency/scalability?
• Is your change adequately tested?
  • Was their sufficient test coverage for the area changed?
  • Do the existing tests capture the requirements for the area changed?
  • Is the bulk of your code covered by unit tests?
  • Does at least one end-to-end test cover the integration points your change depends on?
• Did you update documentation?
• Were there any special dev tricks you had to use to work on this code efficiently?
  • Did you add them to DEVELOPING.md?
• Is this a build change?
  • If so, did you test on both Mac and Linux?

[impl]

Closing in favor of #3155, #3156, and #3157.