Replace the bespoke BRP schedule.graph implementation with ScheduleData.

[andriyDev]

Objective

• A possible step towards Add a first-party schedule visualizer #10981.
• Followup to Create types to store serializable data about the ECS schedule and provide tools for extracting this data. #22520.
• We accidentally have two implementations of the same thing! We created a way to collect schedule data in bevy_dev_tools and in bevy_remote. ScheduleData is a more complete implementation of collecting schedule data, and is less tied to the internals of BRP (e.g., it supports serializing to disk instead of only through the BRP API), so we switch to that.

Solution

• Replace the implementation of schedule.graph with the ScheduleData API.

A disadvantage is that we now need to wait for the schedules to be initialized before we can read them. Since users have to connect with BRP though, it is almost certain that the schedules will be initialized by the time they request the schedules. This may not be true of schedules like state transitions though - since these only run rarely. In a future PR, we can build the schedules on-demand instead.

Testing

• Updated the test for this.
• Ran the same test as BRP Add schedule.graph endpoint #23452
  • Terminal 1: cargo r --example server --features=bevy_remote
  • Terminal 2: curl -d'{"jsonrpc":"2.0","method":"schedule.graph","id":1,"params":{"schedule_label":"First"}}' -X POST -H "Accept: applcation/json" -H "Content-Type: application/json" http://127.0.0.1:15702
  • It dumped out a whole load of JSON that looked expected!
  • I don't have a visualization of the schedule data yet, so I can't validate that it's correct, but there's no reason to believe its wrong given the existing ScheduleData tests.

[andriyDev]

This endpoint was only added in the 0.19 cycle (#23452), so no migration is needed.

[alice-i-cecile]

I would much prefer to standardize on this!