Get ResMut of a resource from World

[Adamkob12]

I can change it so World::resource_mut returns ResMut instead of Mut as well if that's desired, but that could also be added later in a seperate pr.

Let's keep this split this out.

Originally posted by @alice-i-cecile in #11561 (comment)

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

There should be a way to get change-detection-enabled, mutable access to a resource from the World. The type that's conventionally used for that is ResMut

What solution would you like?

Add a method to World that supports that / change the current implementation of resource_mut (and the like) to get ResMut instead of Mut and/or &mut T

What alternative(s) have you considered?

Keep as is

[SpecificProtagonist]

What's the reason for needing both Mut & ResMut? Both are exclusive refs + change tracking, the difference between them is just that ResMut is a system param. There's also an From<ResMut> for Mut.

[lynn-lumen]

What's the reason for needing both Mut & ResMut?

ResMut<T> requires that T implements Resource whereas Mut<T> does not. Since the methods mentioned above are only concerned with Resources introducing this additional bound to them/their return types is sensible.

[SpecificProtagonist]

The issue proposed two alternatives, the former being adding a new method, which I was curious about. I agree with the second one of changing the existing functions :)

[JoJoJet]

We've always treated Mut<T> is bevy's primtive for change detection. The only reason that ResMut exists is because SystemParams don't have methods, so you need to use the type to specify that you are requesting a resource via the type. There's no other reason to use a ResMut instead of a Mut, so we should use them in as few places as possible. We already do this, see how ResMut::map_unchanged and ResMut::reborrow return Mut.

[JoJoJet]

Thank you for the issue, but I'm going to close this since we're likely going to move in the direction described in #11825