Simplify transform hierarchy walk & computation

[Wumpf]

Today, each space view has its own transform context which walks up and down the tree going from $origin in order to figure out transform from each entity/instance to the "reference space", i.e. the space whose origin is at the $origin entity.

So today the graphics pipeline conceptually does the following:

[instance -> entity -> origin-reference] -> camera -> projection

Where the TransformContext is providing [instance -> entity -> origin-reference]

Disregarding (do we have to?) any 2D->3D/3D->2D consideration we could do something much simpler:
First, resolve the transform tree starting at /, let's call this the world space. This leads to the following transform relationship:

[instance -> entity -> world] -> origin-reference -> camera -> projection

Note that now there is a global transform context providing [instance -> entity -> world]. From there on we can either infect re_renderer with this as well - or much simpler - go with this world space and bake [origin-reference ->camera] into the camera matrix we're setting.

-> We end up with a single transform tree pass and don't have to care about walking the tree upwards!

The main issue with doing this today is that 2D in 3D handling makes this complicated in some regards.
Also, there might be several independent 3D spaces that have no connection to the root!

Related, maybe even blocked by:

• Treat camera projected primitives in 3D space more like 2D objects #1025

[Wumpf]

Copying some notes we made on a notion page about on how to address this overall:

## TransformTree

- Store subscriber: Local transforms: Map<EntityPath, BTreeMap<TimeInt, Mat4x4>>
    - GC via minimum timestamp - *a lot* easier than dealing with chunk removals

→ Every frame global transforms are needed

- propagate once
- in every view (view context system): make that tree local to its origin by shiftting all matrices to have the origin as its origin
- every visualizer: look-up its view private thing

## Thoughts on transform tree ranges

- `/a`: `Transform` at `frame=#1`
- `/a/b`: `Transform` at `frame=#1`
- `/a/b/c`: `Transform` at `frame=#3`

- `/a`: [(#1, LocalTransform)]
- `/a/b`: [(#1, LocalTransform)]
- `/a/b/c`: [(#3, LocalTransform)]

Let’s go through a LatestAt(#5):

- You get 3 transforms, and you just multiply them.

Let’s go through a Range [#0, #5]:

- for every possible time, propagate a tree:
    - Tree at latest-at #1 […]
    - Tree at latest-at #3 […]  (note that this tree is an incremental change of the tree at #1)
- What to draw:
    - `/a` shows up once
    - `/a/b` shows up once
    - `/a/b/c` shows up **twice →** AS IF there was pose instancing (generously assuming we implemented that everywhere)

Second scenario:

- `/a`: `Transform` at `frame=#1`
- `/a/b`: `Transform` at `frame=#1`
- `/a/b/c`: `Transform` at `frame=#3`
- `/a/b/c`: `Position=2` (primary) at `frame=#2`

Let’s go through a Range [#0, #5]:

- for every possible time, propagate a tree:
    - Tree at latest-at #1 […]
    - Tree at latest-at #3 […] (note that this tree is an incremental change of the tree at #1)
- What to draw:
    - `/a` shows up once
    - `/a/b` shows up once
    - `/a/b/c` shows up **thrice**
        - transform at #1 with original position
        - transform at #2 with position=2
        - transform at #3 with position=2
    - conceptually: we have draw data for #1 and #2
        - Split those along transform time ranges → two slices, each 1 long
        - each of those slices is then instanced with all transforms that are valid in this range