standardize support features and conformance tests naming and formatting

[LiorLieberman]

As part of #2163 I looked a bit into our current support features and conformance test, their names and their format.

There is a bit of a mess now and if we want to turn this into a part of our API, (as GEP 2162 proposes) we need to first define formatting rules, and adapt the current features and tests to conform those rules.

This discussion has a few goals;

1. Collaborate on the formatting rules for the support features and conformance test names. I will add a proposal in a follow up comment

2. Define what do we want to do with alpha apis. I did find we have a support feature for TLSRoute and for example but did not find one for GRPCRoute.
   Also the one for TLS route is only one feature. Are we happy with it or we have sub features under the object that implementation can opt in? (like we have in HTTPRoute)

3. We have some features like ReferenceGrant that is shared across different objects. What happens if an implementation support reference grant for HTTPRoute but not for TLSRoute? (I might read the tests wrong, so do shout if this question does not make sense)

4. I think we are missing quite a few core features (both for Gateway and for HTTPRoute), do we want to backfill them ? I opened a separate issue for it - Backfill core conformance features for core features #2284

Appreciate your feedback

[LiorLieberman]

One proposal for the supportFeatures naming could be

1. every feature has to start with the Resource name. i.e HTTPRouteXXX
2. retain the ~Pascal case convention. The reason for ~ is that the resource names would not follow the pascal convention purely (HTTPRoute and not HttpRoute)
3. Some char limit - @robscott suggested 128
4. only contain letters and numbers

[youngnick]

Love this proposal, I think it's great.

However, we should also have a rule for how we turn the PascalCase feature names into test file names - I think that right now we effectively do PascalCaseName becomes pascal-case-name.go or similar.

[shaneutt]

I'm +1 for this as well.

[youngnick]

Thanks for getting this started @LiorLieberman!

My feedback here:

Define what do we want to do with beta apis. I did find we have a support feature for TLSRoute and for example but did not find one for GRPCRoute.
Also the one for TLS route is only one feature. Are we happy with it or we have sub features under the object that implementation can opt in? (like we have in HTTPRoute)

I think we should plan for all the routes to have sub features - we may or may not end up using them, but if we don't, we'll definitely need it.

ReferenceGrant is interesting, because it's a security feature - we could almost call this "cross-namespace support", and then ReferenceGrant is how we safely do cross-namespace references. Regardless of what we call it, I think that ReferenceGrants should be tested via their interactions with other resources only.