feat(controllers) add IngressClass v1

[rainest]

What this PR does / why we need it:
Adds an IngressClass controller and store to ingest and cache IngressClasses. Does not actually do anything with IngressClasses after adding them; parser functionality will be added separately.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): This handles the first bullet from #2177

Special notes for your reviewer:

IMO there are two things we should consider here:

• Do we support IngressClass on networking.k8s.io/v1beta1? As proposed this only handles networking.k8s.io/v1, though partly to get feedback on anything we need to change before writing v1beta1 if we implement it (the code will end up being essentially identical). We could reasonably say that IngressClass functionality is only available for v1 and leave v1beta1 support as-is (i.e. it's no different than the old annotation and we only look at ingressClassName in the Ingress). Given the development history I wouldn't expect that there are many users that can use v1beta1 but not v1--they were released within a short timeframe and are identical AFAIK. On our end it's less copy-pasta code to deal with.
• Do we support more than one controller string? As proposed this accepts only ingress-controllers.konghq.com/kong IngressClasses (note that we have a difference between the docs and chart--the latter currently uses konghq.com/ingress-controller). Whether this is configurable or not varies in other controllers based on brief review. The use case would be a single controller ingesting multiple Ingress classes. We could do this, but adding support for that would require refactoring, so it seems like it makes sense to enforce a single IngressClass controller for now to reflect the reality that we still honor --ingress-class and do not allow you to specify multiple or ingest all classes with a given controller string.

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

This only mentions the manifests for now because the code doesn't result in user-facing changes. The controller args are there, but you won't usually use those, and IMO it makes sense to defer mentioning anything other than the manifest to a PR that adds actual IngressClass-based functionality.

[shaneutt]

Overall LGTM, one change requested. I see what you mean about this iteration not really doing anything by itself (just caches the objects but the dataplane code doesn't do anything with it yet) my only thought on that is we shouldn't release this change until we've got the complete support ready, but maybe you were already thinking that.

Do we support IngressClass on networking.k8s.io/v1beta1?

I think no. Version 1 has been out for a long time now so our expectation should be that almost everyone using ingress has upgraded by now. If someone puts in an issue to get support for older versions we can still look into it then but I have my doubts anyone will.

Do we support more than one controller string?

Again I think we should just use the single controller string for the time being, and if someone has a use case that needs something different they can put in an issue for that and we can take a look. Just keep it simple for this iteration.

[rainest]

It's "unreleased" insofar as the changelog doesn't mention any new features other than the new resource in the manifest (which we do want to release soon since some providers, namely AWS, have started rejecting v1 Ingresses that reference a non-existent IngressClass). Code's there for us to build on, but it's essentially inaccessible (the flag to disable the controller is in place but I wouldn't expect anyone to use it). We may or may not implement actual functionality before the next release, but it's not a release blocker if we don't.