Part of more general re_viewer refactor (#1873).

Overview

We want to move towards strongly typed space views that are determined upon creation.

Each SpaceViewType should implement a trait that:

• exposes types that are stored in the blueprint (a trait impl may have additional "ephermeral" state, but that state is not serialized!)
• handles ui interaction
• provide list of SceneElement (new!)
• setup re_renderer viewbuilder internally and return ready command buffer to user
• type name, type icon, help text...

SceneElement is essentially what we refer to as ScenePart so far.
It defines how a single specified archetype is displayed. It can do so by implementing a ui method (which operates on an egui::Ui instance) and/or by returning one or more re_renderer::DrawData.
Concept of archetypes is being introduced as part of

• Project HOPE - codegen of logging SDK and more #2241

By defining a list of SceneElements the trait can provide a list of archetypes!
TODO: This list is probably just internal to the traits internal framework, to the outside we only need a list of archetypes!

Note that any SpaceViewState

Space view types are fixed upon creation, obsoleting

• Allow configuring the kind/category of a space view after its creation #1164

This also replaces the notion of SpaceViewCategory which in this world is dynamically controlled via archetypes. Thus formalizing https://www.rerun.io/docs/reference/viewer/viewport

Sidenote: 2D & 3D space views should be separate type again (with plenty of code sharing though). Removing the "nav mode" again

New crates

• re_viewport, the place where we lay out all the space views. Currently often-times inaccurately to as the blueprint. It also brokers potential state sharing between space views etc..
• re_spaceview, the framework & utilities for defining spaceviews goes to a new crate re_spaceview. re_viewport knows only about the interfaces defined there.
• re_builtin_spaceviews, all built-in ("first party") space views that we have today. Apart from type registry, nothing in the viewer should know about the particular space view types.

With this system it should be fairly easy to provide a native example that registers a custom space view type. We should add a Rust demo doing so!

Checklist

• re_viewport
• re_spaceview
  • SceneElement
  • ...
• traitify existing space views
• custom plugin demo

Some open questions

• can we make good separations between ui, query and re_renderer bridge?
  • it would be desirable to have "pure" crates & trait-impls. But on the flip side it may be much easier to have all these things defined by a single trait
• better name for SceneElement?
• ...