Adding v1 types for Gateway, GatewayClass, and HTTPRoute

[robscott]

What type of PR is this?
/kind cleanup
/kind feature

What this PR does / why we need it:
In prepration for v1.0.0-rc1 (see #2482), this adds v1 types for Gateway, GatewayClass, and HTTPRoute. This also switches over conformance tests to make use of them.

A few notes:

• Conformance tests have all changed to use v1 API versions where available
• Examples are mostly still v1beta1 since they're used in docs, bumped some that were not used in docs, rest will have to wait until after v1.0 is released
• Storage version stays at v1beta1, will get bumped in next minor release
• Continue to recommend that implementations read and write from v1beta1 to support a broader range of GW API versions
• v1alpha2 versions of Gateway, GatewayClass, and HTTPRoute have all gone from "unserved" to "skipped". That means they are no longer part of the CRD at all. Will plan to remove v1alpha2 types in next minor release. Note that this makes the CRD diff look like v1alpha2 was renamed to v1.

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: robscott

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [robscott]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[robscott]

This is a massive PR, want to make sure we've got everything in order before merging.

/hold

[shaneutt]

If I'm not mistaking this approach will lose the commit history for these files, and people's attribution. It should be possible to do some git tricks to copy the file in a way that it will continue tracking its history and attribution. One example of how this can be accomplished: https://stackoverflow.com/questions/16937359/git-copy-file-preserving-history

[robscott]

@shaneutt I've spent some time looking into this, but I'm not sure that I'll have time to resolve this today. There's a lot of nuance and complexity in this PR, and the steps to maintain git history here seem unfortunately complex. For what it's worth, we did not maintain git history when transitioning from v1alpha2 -> v1beta1, and I can't find any examples of maintaining history for similar transitions between API versions in upstream Kubernetes. So although I agree that this would be nice to have, I personally don't think it should block this change (and corresponding release candidate).

[youngnick]

/lgtm

[robscott]

/hold cancel