Make re_edit_ui its own crate

[Wumpf]

What

Adds a new leaf crate to the viewer crate ecosystem.
While working on edit/data uis I noticed that most of the things in this crate just register ui and aren't used anywhere else. Unfortunately, re_data_ui provides various non component ui (causing it to become a more basic crate) and the orphan rule makes it fairly hard to move things out. So far however, edit uis have been untained by this! I want this to stay this way since:

• changing edit ui is a frequent operation
• this is an easy opportunity to have crate compilation up to re_viewer itself stay wide

As we provide more and more edit ui we might end up where we prefer edit ui over display ui when available (using a disabled edit ui) which means that over time re_edit_ui will be more important. Having it be only a dependency of re_reviewer ensures a clean architecture.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using examples from latest main build: rerun.io/viewer
  • Using full set of examples from nightly build: rerun.io/viewer
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!

• PR Build Summary
• Recent benchmark results
• Wasm size tracking

To run all checks from main, comment on the PR with @rerun-bot full-check.

[emilk]

I'm curious about what

cargo install cargo-depgraph
cargo depgraph --all-deps --workspace-only --all-features --dedup-transitive-deps | dot -Tpng > deps.png
open deps.png

looks like these days

[Wumpf]

@emilk I did a before after here recently
#6431 (comment)

As expected, this adds another direct dependency to re_viewer:

(unfortunately doesn't place it nicely though)

Again, 0.16: