Alternate wireframe override api

[IceSentry]

Objective

#7328 introduced an API to override the global wireframe config. I believe it is flawed for a few reasons.

This PR uses a non-breaking API. Instead of making the Wireframe an enum I introduced the NeverRenderWireframe component. Here's the reason why I think this is better:

• Easier to migrate since it doesn't change the old behaviour. Essentially nothing to migrate. Right now this PR is a breaking change but I don't think it has to be.
• It's similar to other "per mesh" rendering features like NotShadowCaster/NotShadowReceiver
• It doesn't force new users to also think about global vs not global if all they want is to render a wireframe
• This would also let you filter at the query definition level instead of filtering when running the query

Solution

• Introduce a NeverRenderWireframe component that ignores the global config

---

Changelog

• Added a NeverRenderWireframe component that ignores the global WireframeConfig

[alice-i-cecile]

@Wcubed, opinions here?

[alice-i-cecile]

This is clean, and should be meaningfully faster. This is a better way to tackle this I think.

[Shatur]

Like the consistency with other engine API.

[rparrett]

It's similar to other "per mesh" rendering features like NotShadowCaster/NotShadowReceiver

Also NoFrustumCulling and now NoAutomaticBatching.

Bikeshedding: How do people feel about NoWireframe?

[IceSentry]

I originally started with NoWireframe but switched while making the PR. I don't even remember why 😅 because I prefer NoWireframe

[alice-i-cecile]

@IceSentry swap to NoWireframe and I'll merge this for you :)

[Wcubed]

I agree on all of the benefits listed. This indeed looks like the better way to handle this :)

This does make me think though: If we have multiple "mutually exclusive" components, or basically enums disguised as components for significant benefits, do we want to add any type of guarding or checking functionality to this? Because the one thing we lose is rusts guarantee that an enum is one and only one value. In this case there are two components that are related, but in a game there could be many more cases, and then keeping them disjoint could get error-prone.
But that's a discussion for another place I think.
Edit: Looks like it might be related to #6556

[alice-i-cecile]

This does make me think though: If we have multiple "mutually exclusive" components, or basically enums disguised as components for significant benefits, do we want to add any type of guarding or checking functionality to this?

Described in #1481 :) It's a good idea!