Move heuristic for viable space view "candidates" to space view class

[Wumpf]

• Sparked by investigating Slowdown with 1'000 entities #2285

We figured out in the process that as long as auto-adding space views is enabled we take a significant amount of time determining them.

@jleibs and me discussed how to improve the way we do space view heuristics in the future and came up with a new schema where each space view class would decide on its own heuristic (this has the added benefit of removing remaining knowledge of specific views from re_viewport. The heuristic method per class would look something like this:

    fn auto_spawn_heuristic(
        &self,
        ctx: &ViewerContext<'_>,
        ent_paths: &PerSystemEntities,
        max_num_candidates: usize,
    ) -> Vec<(AutoSpawnHeuristic, EntityPath)>;

Meaning that candidate creation can be done in a much more sensible way. Some challenges there are dealing with disconnected-components.

Why does this help performance?
Right now we have an unrealistic large number of space view root candidates for which we determine which entities should be added for each possible space view class.
Instead, each class actually has a relatively limited set of candidates in the first place. Furthermore, only some of these candidates need to determine which entities they will contain by default in order to determine a heuristic score!