Expose ui based radii, remove view default radius setting

[Wumpf]

With the introduction of per-view default components we're able to remove the old default line & point radii.

However, this ui allowed you to set radii in ui points, something which is not possible today from components.
We decided to solve this by introducing a new RadiusUi (or UiRadius) component which can live side by side with regular Radius on affected archetypes. Whenever RadiusUi is present, we pick it over regular Radius.

This has some (simplifying!) ripple effects in the renderer: point & line batches would have a flag to determine whether they are world or ui sized. We drop support for mixing ui & world sizes on the same batch/entity.

Note that this fits a fallback interaction case that we only speculated on so far: Naturally both RadiusUi & Radius have a fallback (all components have!), but visualizers need to know if any of them was a fallback so they can pick the other.

Tbd:

• if a ui size is set, make points flat shaded and don't simulate spheres? Seems like the right thing to do!
  • depth adjustment as done by Render points with per-fragment depth, improving visuals for points intersecting with other geometry #6508 can be skipped then
• how we deal with two active fallbacks (Radius & RadiusUi) in the ui? We could set one of the fallback values to Nan in order to signal that it should be unused.

Affected archetypes:

• arrows2d/3d
• boxes2d/3d
• line_strips2d/3d
• points2d/3d (including key point connections)

Obsoletes:

• Default line/point radius not saved in .rbl files #6228

Related to:

• Render points with per-fragment depth, improving visuals for points intersecting with other geometry #6508
• Distinguish points, spheres and circles #2689
  • Somewhat obsolete now, but we haven't figured out yet how spherical points3d is going to be in the long run. We likely still want "proper" spheres which also offer outline rendering abilities.

Discarded alternatives:

• archetype variants which determine the semantics
  • Point vs Sphere, Line vs UiLine?, etc.
  • Con: Tricky naming, hard to switch back and forth right now
• special datatype that mirrors what we do on re_renderer
  • Con: Requires user to bulk negate values if they want ui units
• additional enum value to determine semantic of radius component
  • Con: Radius component no longer has full sematantic

(this was a result of a meeting between @jleibs @emilk & @Wumpf + some additional thoughts that came up during writeup )

[emilk]

A RadiusUi component should replace MarkerSize (which btw hasn't documented if it is a radius or a width, and consequently the code treats it differently in different places)

[emilk]

RadiusUi could potentially replace StrokeWidth too

[Wumpf]

@jleibs and me rolled up the case again and looked at the pros and cons in the light of the new features that landed since we talked last about this two weeks ago.

One major issue we identified with the so far proposed side-by-side RadiusUi + Radius was that it sets an awkward precedence in the ui where you can’t tell whether a component participates in visualizing a thing - one of the problems that the new ui was supposed to tackle. This could be a systemic “use either or” thing, but it seemed rash to extend the system in such a way at this point.
The many-archetypes + RadiusUi component proposal has some merit - more than originally because switching visualizers is easy now - but creates a flood of code duplication on all sides.
A subproposal came up to only duplicate Visualizers, but that would break the 1:1 archetype visualizer relationship we wanted to gravitate towards
The enum proposal (single radius but extra enum to interpret it) was still discarded on grounds of sidestepping semantics, but there was some positive leaning toward it in the, ehrm, group.
Which leaves us with “just expose our internal data as is” == negative Radius implying ui type as well as making radius a union. Jeremy strongly supported the union idea, but we identified some practical issues with it upon processing the data (none of them unsurmountable)
We figured eventually that the union proposal is almost identical to exposing our internal data as-is: Negative radii are interpreted differently.
Previously, when this came up we were afraid of the user having to do large bulk operations on this, but we concluded that this is rarely the case: Having radius differ over the instances (individual points, individual line segments) is very rare and when it happens it is likely because there is a world size correlation!

=> We’re decided unanimously for negative Radii == ui radius + utility methods (similar to re_renderer’s Size type) + custom ui (in order to show semantic, not +/- signs)
This also happens to be the only proposal that we can implement relaistically for 0.17 as it minimal form requires almost no changes (docs + remove warnings + a bit of ui)