Allow write access in NestedQuery

[tim-blackbird]

Objective

Remove the ReadOnlyQueryData bound on D for NestedQuery<D, F>

Solution

As far as I could tell the only remaining issue here is the need to store the the same QueryState for both QueryData and QueryData::ReadOnly, but that same bound allows us to soundly transmute between the State of D and D::ReadOnly as much as we want.

Hopefully I'm right about that, kinda awkward otherwise

Notes For Reviewers

• I've dug into bevy_ecs guts before but I'm not great with unsafe code generally so this needs a good look. This change could be totally wrong :) (also it's past 2:00 AM. help)
• See 5067e4b for a temp relationship QueryData impl yoinked from Nested Queries #21557's description for testing these changes.
• I also removed the ReadOnlyQueryData bound for QueryState::as_transmuted_state. I don't think that's an issue?
• The safety doc for as_transmuted_state isn't quite precise enough. In this PR I effectively do the exact opposite of what it says is safe. I use to_readonly to get D::ReadOnly and then use as_transmuted_state to get back to D. I feel it should reference the D and F the state was created with instead of the D and F it currently has?
• The QueryState::to_readonly impl is kinda funny, hihi

Testing

Mirrored the existing NestedQuery tests to check that the mutable access within NestedQuery correctly conflicts with other accesses.
In 5067e4b there are some tests including one that mutably accesses a component through the inner NestedQuery.
This simple test passes miri at least.

Hi! :3

[chescock]

Oh! Hah, I was just about to create a PR with a different approach to this when I saw this one had been opened :).

... Ah, okay, you're storing QueryState<D::ReadOnly, F> so that the types match. That's what I tried at first, and I believe it is sound, but it's really hard to prove that in the safety comments. As you note, you're doing the opposite of what the safety comment in as_transmuted_state says :).

Let me go open my PR with the other approach for comparison. ... okay, #25652! And now I'm going to go copy the unit tests from this PR, since I didn't think to write any.

[chescock]

That said, I'm happy to go with this approach if we want! I do think it works, but we'll probably want to adjust the safety comments a bit to make it clear that it works.

[chescock]

This safety requirement will need to be changed if we take this approach, since it's not satisfied by the calls in NestedQuery.

[chescock]

I think this needs to be changed somehow, too, but I couldn't figure out what to write here.

We need to show that we call QueryState<D, F>::init_access and not QueryState<D::ReadOnly, F>::init_access, and we might need to modify the safety requirements on new_unchecked, since it doesn't currently allow that sort of shenanigans.

Or maybe I was overthinking it and this is just fine, since the transmutes are obviously opposites of each other?

[tim-blackbird]

I think your thought process here sums up why I feel your implementation is better :)
This transmute hokey pokey does feel "simply" correct considering the constraints, but it's messy and hard to pin down exactly

[chescock]

This bound should be loosened, too.

Suggested change

	impl<D: QueryData, F: QueryFilter> ArchetypeQueryData for NestedQuery<D, F> {}

Hmm, GitHub is being weird about suggestions on lines you didn't change.

[tim-blackbird]

I'm inclined to close this in favor of #25652