Show first line of the docs when hovering a component name

[emilk]

What

• Part of Improve tooltips for overrides and defaults as well as for enums  #6556

Now that we can override all kinds of components in the UI, we should also take care to explain them to the user.

Previously all the user had to go on was the name. With this PR they get the first line of the docstring for the component, plus a link to the full docs on our website.

This required adding a new (generated) reflection API.

Best reviewed commit-by-commit.

Related

• CommonMarkViewer adds empty veritcal space around it lampsitter/egui_commonmark#54

Later PR

• Refactor: merge ArchetypeFieldInfo into the reflection module #6616

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.

[Wumpf]

Part of

• Improve tooltips for overrides and defaults as well as for enums  #6556

Haven't looked at anything yet, but this should also drag in the opt-in archetype field documentation we have via attribute ( (attr.rust.generate_field_info) into this new crate if it doesn't already.
(that's used for generating doc strings on all view properties that follow the generic ui)

[emilk]

re_types_registry is a dynamic registry, mapping ComponentName (and, int the future, ArchetypeName) to some info at runtime. At the moment it is only code-generated, but we could add support for registring new components at runtime too.

Archetype::field_info seems like a slightly different beast, though I guess it could too be moved to re_types_registry if we change the lookups from a static A::info() to a dynamic re_types_registry::get_archetype(A::name()). I think this is best suited for a follow-up PR.

[Wumpf]

dynamic lookup via archetype name would be preferable anyways I think! The more we can pass ArchetypeName/ComponentName instead of A: impl Archetype/C: impl Component the better 👍

[Wumpf]

Let's not stack the crate hierarchy deeper when we don't have to!

As for name: re_types_registry is quite at odds with component type registration in the store. I'd rather call it by what it does re_types_meta_info or something

[Wumpf]

nice!!

[Wumpf]

(resolved merge conflicts)