Separation & improved book-keeping of entity -> visualizer assignment

[Wumpf]

What

• Part of:
  • Pay off accumulated debt from DataQuery refactor #4377
  • Re-engineer the space-view heuristics engine #4388

Previously, we assumed that the heuristic_filter on applicable entities (== entities that fullfill all required components and some additional global properties as determined by store subscriber) applies on a per space view class basis.
However, this is not entirely accurate and misses that "visualizability" is determined on a per-space-view-instance basis: The most prominent example of this is that a 2D primitive may or may not be visualizable in a 3D view depending on where the 3D origin is.
Another, more forward looking problem was had in this area is that heuristic_filter of visualizers should be applied as part of the query since a query determines whether visualizers are picked automaticall/all/single.

This PR separates all these concerns more clearly and introduces types wrapping lists of entities to make it harder to confuse which set represents what:

• ApplicableEntities
  • global set, already produced by a store subscriber
• VisualizableEntities
  • produced per space view instance. Space view instances can compute a context (replaces HeuristicContext!) to guide their systems. This is an Any which allows visualizer systems to react to different "parent" space views!
• IndicatorMatchingEntities
  • global set, already produced by a store subscriber
  • to be used as base for the "ActiveEntities" for each visualizer. For simplicity the "ActiveEntities" itself is right now not a type. Instead, the query uses IndicatorMatchingEntitiesand passed in VisualizableEntities on the fly to determine this final set. In the future it:
    • may opt out to do so because a query warrants a specific visualizer(s)
    • may opt out to do so because a query warrants all possible visualizers
    • visualizers and/or classes may modify the heuristic set

Great care was taken to not regress performance of the (still per frame applied) heuristics. However, since we're doing a lot more work now there's still a bit of a performance hit:

Before:

After:

I decided that any further improvements in this area should be done in the context of not recomputing heuristics every frame and instead react to relevant changes. (#4388)

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using newly built examples: app.rerun.io
  • Using examples from latest main build: app.rerun.io
  • Using full set of examples from nightly build: app.rerun.io
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[jleibs]

Really happy with how this all turned out. So much cleaner. Thanks for the thorough walkthrough.