Flexible Reflection Paths

## What problem does this solve or what need does it fill?
Let's say you are given a reflection path, and you don't know the type to expect on the other side, or the intention of this reflection path.

Let's assume the type:
```rust
struct Stucty {
inner_tuple: Tuply,
list: Vec
}

struct Tuply(pub String);
```

I want these paths to be able to accees anything in the Structy type. With that in mind let's assume we're just yoinking the paths through `ParsedPath::parse`.

In this case whoever is providing the paths, to access the tuple string, I'd need to receive:
```rust
inner_tuple.0
```
to access the list I'd need:
```rust
list[0]
```

Now let's say these paths are coming from your bog standard scripting language, the user can only specify their intentions in the following ways:
- `[]`
- `[]`
- `.`

How would these paths look like with these limitations?
- `inner_tuple.0` would be: `.inner_tuple[0]` right?
- `list[0]` would be: `.list[0]` and so on

But hold on a minute, assuming I am doing these accesses one at a time (for the sake of brevity, I think it works out the same anyway):
- "inner_tuple" -> gets parsed to field access
- [0] -> gets parsed to tuple access

So then both paths cannot be valid! The tuple struct requires a tuple access whereas the list requires a list access!

So then as the mediator I have to "differentiate" between these types of accesses somehow. In the case of `bevy_mod_scripting` I currently do this by lettting users use `_1` to mean tuple access, and `[1]` to mean list access.

Ideally I don't want the user to have to know anything about the internals of reflection. At the moment they can use `[]` to use the full reflection path syntax, but I wouldn't want this to be the primary way of interacting

## What solution would you like?

- Reflection paths which do not assume what the target "kind" is at the time of parsing

## Additional
The commitment you have to make ahead of time:

BMS examples:
```lua
assert(retrieved._1 == "Initial Value", "Resource should have default value but got: " .. retrieved._1)
assert(retrieved["1"] == "Initial Value", "Resource should have default value but got: " .. retrieved["1"])
```

Start by reading the existing ParsedPath::parse behavior and the reflection path syntax described in the issue, then compare it with the bevy_mod_scripting examples. Define how paths can remain valid without knowing the target kind during parsing, and document or test the intended behavior for tuple fields and list indexing.

Written by the indexing model from the issue text.