BRP resource methods

[mweatherley]

Objective

So far, built-in BRP methods allow users to interact with entities' components, but global resources have remained beyond its reach. The goal of this PR is to take the first steps in rectifying this shortfall.

Solution

Added five new default methods to BRP:

• bevy/get_resource: Extracts the value of a given resource from the world.
• bevy/insert_resource: Serializes an input value to a given resource type and inserts it into the world.
• bevy/remove_resource: Removes the given resource from the world.
• bevy/mutate_resource: Replaces the value of a field in a given resource with the result of serializing a given input value.
• bevy/list_resources: Lists all resources in the type registry with an available ReflectResource.

Testing

Added a test resource to the server example scene that you can use to mess around with the new BRP methods.

Showcase

Resources can now be retrieved and manipulated remotely using a handful of new BRP methods. For example, a resource that looks like this:

#[derive(Resource, Reflect, Serialize, Deserialize)]
#[reflect(Resource, Serialize, Deserialize)]
pub struct PlayerSpawnSettings {
  pub location: Vec2,
  pub lives: u8,
}

can be manipulated remotely as follows.

Retrieving the value of the resource:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "bevy/get_resource",
  "params": {
    "resource": "path::to::my::module::PlayerSpawnSettings"
  }
}

Inserting a resource value into the world:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "bevy/insert_resource",
  "params": {
    "resource": "path::to::my::module::PlayerSpawnSettings",
    "value": {
      "location": [
        2.5, 
        2.5
      ],
      "lives": 25
    }
  }
}

Removing the resource from the world:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "bevy/remove_resource",
  "params": {
    "resource": "path::to::my::module::PlayerSpawnSettings"
  }
}

Mutating a field of the resource specified by a path:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "bevy/mutate_resource",
  "params": {
    "resource": "path::to::my::module::PlayerSpawnSettings",
    "path": ".location.x",
    "value": -3.0
  }
}

Listing all manipulable resources in the type registry:

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "bevy/list_resources"
}

[purplg]

This looks good to me. Excited to see these new methods implemented.

Do we want to consider renaming the methods to be a little more hierarchical in the future or maybe some other scheme? For example:

• bevy/mutate_component -> bevy/component/mutate
• bevy/list_resources -> bevy/resource/list
• bevy/insert_resource -> bevy/resource/insert
• bevy/remove_resource -> bevy/resource/remove
• bevy/mutate_resource -> bevy/resource/mutate

I feel like they may get a little unwieldy over time as more and more methods are added.

[mweatherley]

Do we want to consider renaming the methods to be a little more hierarchical in the future or maybe some other scheme?

This is a very good idea. I'll change them when I have time :)

(I guess there's also the question of which other methods, if any, should get moved to the bevy/component/ namespace.)

[alice-i-cecile]

Straightforward, tested and uncontroversially useful. Thanks!

[alice-i-cecile]

@Leinnan I actually need a second review over here. Can you do a pass on this?

[Leinnan]

Really minor: this could be imho named get_type_registration since it would work the same way for the non resource type. In case that is changed, change also the resource_path argument name.

[Leinnan]

Really good job. :D I've tested it locally, works great! I agree with @purplg that names could use cleanup and I would love that to happened before 0.16 release. But this is a separate change so I've created ticket for it: #18055

[alice-i-cecile]

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#1997 if you'd like to help out.