Conformance and Support matrix enhancements

[youngnick]

This may end up being a GEP, but this issue is to discuss enhancements to the conformance process, with a couple of end goals in mind:

• As a user of Gateway API, I should be able to look at the status of GatewayClass and see information about what features the reconciling implementation supports.
• As a user of Gateway API, I should be able to consult a feature matrix to determine which implementations support which features. These features should be supported by and/or derived from conformance information. (Thanks @candita for the suggestion!)

A related goal is:

• as a Gateway API implementer, the conformance tests I run should be able to autodetect what features are supported and conformance test them automatically.

I've linked these together in this issue because the schema we'll need for the first will end up looking a lot like the column for the second, and that schema will probably be closely related if not identical to what we'll need from the conformance tests too.

[youngnick]

I think it's relevant to call out a few things that the schema will need to track;

• Supported Route types
• Extended features available in various objects. It may be better not to namespace the extended features by object though.

I think we'll also need to get more specific about which objects must always be watched, and which ones can be watched sometimes. I'll make another issue about that now.

[candita]

I would add:

• Supported versions (alpha, beta, experimental, standard, semantic versioning, or other)

@youngnick would you mind moving the "related goal" conformance test linking to a different issue? It could really complicate a fairly simple support matrix to add conformance test linking as a type of acceptance criteria.

[youngnick]

I agree that supported versions should also be included, agreed.

I'd like to leave that note in here, but should add that it's not necessary to complete this effort.