Find and remove all ComponentRegistry misuse.

[moonheart08]

A shocking amount of code treats it as a collection of component types, instead of a collection of instantized components. This is not only wasteful (as you must instantiate components you then don't use), but also actively confusing (people seem to expect the thing only intended to instantiate entities to be some kind of pattern they can match on. This is not how it works and we cannot implement component pattern matching in any reasonable way.)

These all need replaced with a HashSet<Type>.

ComponentRegistry itself needs rewritten to not inherit from Dictionary and spill internal details, for ease of use.

Current culprit APIs in engine:

• CompRegistryQueryEnumerator
  Also needs optimized to look up all trait dictionaries in advance. The query can never change, so we can rewrite the whole thing to "does this entity exist in all of these trait dicts?"
• ComponentQueryEnumerator, ditto w/ above.`
• AddComponents/RemoveComponents. Rather, AddComponents needs an overload that accepts a set of types, and RemoveComponents needs to only accept a set of types.

[Tayrtahn]

Content sometimes uses ComponentRegistry as a way to let yaml prototypes specify a list of component types to be used as a filter. If those are to be converted to HashSet<Type>, we should provide a convenient way of doing yaml validation for those. Possibly also a a way to write them in yaml without needing !type: for each entry (maybe by string component names instead of Types?)

[moonheart08]

Content sometimes uses ComponentRegistry as a way to let yaml prototypes specify a list of component types to be used as a filter. If those are to be converted to HashSet<Type>, we should provide a convenient way of doing yaml validation for those. Possibly also a a way to write them in yaml without needing !type: for each entry (maybe by string component names instead of Types?)

I'm aware and I'd just make a new type with its own serializer for this. ComponentRegistry's use by content as a filter list is incorrect and a new type should've been made a while ago.

[Tayrtahn]

Yep, that's what I was thinking too. Figured it was worth mentioning for anyone looking to resolve this issue.

[moonheart08]

All issues in this PR are now addressed by #6442 (first and last) and #6446 (middle).