Add enum variant index to GetPath

[IronGremlin]

Objective

Currently, the machinery provided by Bevy's GetPath trait is agnostic about which enum variant it provides access to.

This limitation prevents users from disambiguating between identically named fields on variant structs (ehh...) or indices on variant tuples (EG, there's no way to disambiguate access between say, Result::Ok or Result::Err).

Historically, this ability to disambiguate hasn't been necessary to support common reflection cases, as we can generally assume that under reflection, you have an instance available to reflect, and can therefor interrogate the structure of the instance if you really need to.

However, as The Editor (tm) fast approaches, a new category of use-cases for bevy_reflect are being uncovered -
They include such cases as:

• Abstractions on top of reflection, such that an AccessPath may need to be constructed without access to an instance of a type
• Overrides for CustomAttribute (or similarly stored future concepts) data to decorate editor functionality at runtime - allowing the TypeRegistry or similar, editor/inspector-specific resource to play host to arbitrary field level data

Imagine, for example, some resource -

HashMap<(TypeId, AccessPath), &dyn MyMagicWidgetBuilder>

where a tool author might be able to selectively override inspector widget construction for their project.

Today, we can't build that, because AccessPath can facilitate arbitrary structural access for an instance, but the inability to discriminate between enum variants means it can't express arbitrary structural access for a type.

Solution

Implement a minimal adjustment to GetPath to support discrimination between enum variant indices.

Testing

Changes necessary to support this feature were small enough that the existing test suite was able to provide adequate coverage with only minimal additions.

Showcase

Example of accessing an enum under reflection today:

let six = Some(6).path::<u32>(".0").unwrap();

Example of proposed change:

let six = Some(6).path::<u32>("{1.0}").unwrap();

Alternatives and Disclaimers

I do not understand the current design choice.

I'm not sure why we chose not to do this originally.
It is very possible I have overlooked some vital use-case that my change would invalidate or over-complicate.

This syntax is kinda gross

I'm not really a huge fan of this syntax.

The current implementation of Access relies on being able to jam the Token enum into a u8 - I did what seemed sensible with the token space available. It seems extremely plausible that better ideas exist here.

We could support this but not require it

I started with an even smaller version of this change that would make specifying the enum variant index optional - the syntax would work largely as is, but you could optionally supply an enum variant index and Access would validate it for you if it found one.

I'm still not entirely confident that's not a superior option, but I ended up doing this instead simply because I kind of stalled out trying to write docs that adequately explained what good optional validation would be to anyone without info-dumping my editor design manifesto into a doc comment.

We could just not do this.

We could also just re-implement most of this machinery in a more specifically targeted fashion for Inspector/Editor use instead.

For my part, I believe expanding this concept very slightly to support adjacent use-cases makes more sense than re-implementing this elsewhere, but I also feel I am largely ignorant of the full scope of the design goals for bevy_reflect, and could certainly be wrong.

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.