reflect: TypePath part 2

[soqb]

Objective

• Followup to reflect: stable type path v2 #7184.
• Deprecate TypeUuid and remove its internal references. No longer part of this PR.
• Use TypePath for the type registry, and (de)serialisation instead of std::any::type_name.
• Allow accessing type path information behind proxies.

Solution

• Introduce methods on TypeInfo and friends for dynamically querying type path. These methods supersede the old type_name methods.
• Remove Reflect::type_name in favor of DynamicTypePath::type_path and TypeInfo::type_path_table.
• Switch all uses of std::any::type_name in reflection, non-debugging contexts to use TypePath.

---

Changelog

• Added TypePathTable for dynamically accessing methods on TypePath through TypeInfo and the type registry.
• Removed type_name from all TypeInfo-like structs.
• Added type_path and type_path_table methods to all TypeInfo-like structs.
• Removed Reflect::type_name in favor of DynamicTypePath::reflect_type_path and TypeInfo::type_path.
• Changed the signature of all DynamicTypePath methods to return strings with a static lifetime.

Migration Guide

• Rely on TypePath instead of std::any::type_name for all stability guarantees and for use in all reflection contexts, this is used through with one of the following APIs:

  • TypePath::type_path if you have a concrete type and not a value.
  • DynamicTypePath::reflect_type_path if you have an dyn Reflect value without a concrete type.
  • TypeInfo::type_path for use through the registry or if you want to work with the represented type of a DynamicFoo.

• Remove type_name from manual Reflect implementations.

• Use type_path and type_path_table in place of type_name on TypeInfo-like structs.

• Use get_with_type_path(_mut) over get_with_type_name(_mut).

Note to reviewers

I think if anything we were a little overzealous in merging #7184 and we should take that extra care here.

In my mind, this is the "point of no return" for TypePath and while I think we all agree on the design, we should carefully consider if the finer details and current implementations are actually how we want them moving forward.

For example this incorrect TypePath implementation for String (note that String is in the default Rust prelude) snuck in completely under the radar.