What problem does this solve or what need does it fill?

Being able to access &(mut) dyn Reflect fields from a larger dyn Reflect via GetPath is a very nice QOL option when loading scenes or just looking for a runtime reflection. However, repeatedly calling it's functions with the same string is wasteful as it re-parses the same string at every call.

What solution would you like?

It'd be ideal to have alternative APIs for parsing a field path ahead of time, and just using the parsed token stream or access-list.

Ideally this would also look up type registrations, possibly using static type information (#4042) to look up field numbers instead of using string based lookups to help further cut down on string operations on this fast-path.

What alternative(s) have you considered?

• Manually implementing a token-stream based equivalent to path, path_mut, get_path, and get_path_mut. This would work for this one use case, but wouldn't be generically available as a fast-path for other use cases.
• Pseudo-JIT compilation for creating runtime lenses for extracting references for a given type. This would probably be the most efficient way to do so, but also the most complex.

Additional context

This is an optional, but highly recommended optimization for #4026 to enable faster application of animated values.

The current code already tokenizes individual parts of the path. We'd just need to decouple this into a separate 'static token stream that can be used as an alternative input.