m/space: Refactor apply_relation

This an alternative to !2142 (closed), which only treated one of the symptoms. This addresses the root cause, which is basically that in our space graph the base case defaults to not tracked/no valid velocities. That means specifically for relating to poses that the result is not tracked/no valid velocities; whereas the base case of locating two "offsets to the same thing" is tracked and probably has valid velocities in OpenXR. Lemma: Every relation in OpenXR is tracked by default, unless to figure out the relation you have to query a relation that is currently not known.

Example configuration:

A: offset space to stage space -> B: stage space (tracked pose known to the runtime) -> C: controller space (tracking lost, tracked pose in stage space not known to the runtime) -> D: offset space to the controller

• Relation from A to B or B to A: tracked, velocities known.
• Relation from C to D or D to C: tracked, velocities known.
• Relation from B to C or C to B: not tracked, no valid velocities.
• Relation from A to D or D to A: Not tracked, velocities not known.
• etc.

Before, apply_relation had unclear semantics and "upgraded" relation flags to valid if either one of the relations had them. Most likely this was because poses were considered to be not tracked and not having a velocity.

But OpenXR behavior says that something that is just an offset to something else, for example local stage in stage space should have tracked flags, and probably velocity valid flags.

The only time when something is not tracked in OpenXR is when the path through the space graph passes through a space that actually tracks something with a tracking system that currently can not track that something. (Or when two spaces are in disjunct partitions of the space graph).

Therefore, insert poses as fully tracked relations with zero velocities into the relation chain and remove all the "upgrade" behavior.