feat(controllers) handle default IngressClass

[rainest]

What this PR does / why we need it:
When 'ingressclass.kubernetes.io/is-default-class: "true"' is present on the ingress controller's configured IngressClass, ingest class-aware resources that have no IngressClass set.

Add a new watch to reconcilers, which requeues objects if the default IngressClass changes. This ensures that existing classless objects are ingested if our class becomes the default class during operation.

Rework utility functions related to class matching to make default class handling work.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): part of #2177

Special notes for your reviewer:
This originally only applied to Ingress objects, as their link to IngressClasses is the only link actually in the spec. In retrospect during development it seemed odd that you'd have a default class that ingested classless Ingresses while you still needed to apply the class to everything else.

We did have heterogenous classless handling (i.e. classless Ingresses supported, but not classless KongClusterPlugins) with the expectation that the de facto classless handling behavior would go away entirely with Ingress v1 and the dedicated ingressClassName field. As that didn't happen, and default/classless handling is now a de jure part of the spec, I've applied it across the board.

FWIW #853 has been exacerbated by the addition of the controller-level filters, as the duplication of effort here demonstrates.

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

[rainest]

Lint and unit currently broken due to a function name change; test updates are pending me figuring out a good way to organize the additional cases. The below should still be reviewable as-is.

409e959 reworks the utility class matcher(s) to try and address the comments related to it and consolidate some code.

We originally had predicate generators allow toggling whether the resource allows the netv1 Ingress spec field and/or the annotation to manage it, though I don't think that was strictly necessary--the try everything approach should work fine. The spec field is present only on a single type that we have to cast to when checking anyway, and everything accepts the annotation.

We mention that the annotation is deprecated (and I think this may be why we had those options) but it's kinda weird to deprecate an annotation since you can't remove specific annotations from a spec, and thus implementation is entirely on the client side. There's probably no great reason to actually remove support unless we want to make a clean cut away from the old annotation, since you can always simply not use it (assuming we eventually add dedicated fields to our CRDs in the future).

[shaneutt]

Looking good, once the commits that resolve #2313 (comment) are in I'll do a final pass.

[rainest]

No luck trying generics so whatever, the number of types we need to check isn't that huge (the Ingress annotation check covers almost everything since it's the same annotation throughout; netv1 spec and Knative are the exceptions), so I went ahead and just duplicated the loops for each.

Also rolled the separate commit showing the changes to MatchesIngressClass and friends into the previous one, since it's been reviewed and was only separate to highlight the change.