Allow BRP schedule.graph to initialize the schedules it is collecting.

[andriyDev]

Objective

• In Replace the bespoke BRP schedule.graph implementation with ScheduleData. #23733, we started using the ScheduleData API for the BRP schedule.graph endpoint.
• This had a consequence that only schedules that were initialized (i.e., previously ran) could be returned.
• In addition, the schedule data was missing edges for automatically inserted apply_deferred systems.

Solution

• Cache the ScheduleBuildMetadata whenever a schedule is built (the ScheduleBuilt event).
• Lookup this metadata when BRP schedule.graph runs, and use it to extract the schedule data.
  • This metadata includes the edges for automatically inserted systems, making the resulting ScheduleData more accurate to the running schedule.
• If the schedule needs to be built (has changed/hasn't run before), build the schedule which automatically caches its metadata.

Testing

• Added a test for this.

[ChristopherBiscardi]

would heavily prefer we asserted that these systems are the systems we expect. I recently ran into a test suite that only used the counts like this in an ecosystem crate and it was more confusing to fix than it needed to be, since the test didn't include which items it expected to exist other than the count.

As an example (anything similar would be fine if you prefer .find or something):

Suggested change

	assert_eq!(response.schedule_data.dependency.len(), 3);
	assert!(response.schedule_data.systems[0].name.ends_with("f1"));
	assert!(response.schedule_data.systems[1]
	.name
	.ends_with("apply_deferred"));
	assert!(response.schedule_data.systems[2].name.ends_with("f2"));
	assert_eq!(response.schedule_data.dependency.len(), 3);