New status conditions for unsupported (non-core) features

[mlavacca]

Since the API has a bunch of non-core features (either extended or experimental), and GEP-1709 plans to assert the various types of conformance through a set of profiles, it could be helpful to introduce a new status condition related to the non-core unsupported features, to standardize the way the user gets feedback about not-supported Gateway API features.

For example, if a user creates an HTTPRoute with a ResponseHeaderModifier filter set, but the implementation does not support such a feature, it could be useful to have a standard and shared way to state that the HTTPRoute is not valid because the feature is experimental and not supported by the implementation.

[shaneutt]

I believe this need is already captured by #1804 (which as it stands we're pushing to resolve before GA). Can you look that issue over and let me know if you feel it doesn't fully cover what you want, or if there are ways we can improve the wording to better include your needs?

[mlavacca]

That issue is precisely what I was looking for; thanks for pointing me!