Create types to store serializable data about the ECS schedule and provide tools for extracting this data.

[andriyDev]

Objective

• A step towards Add a first-party schedule visualizer #10981.
• Allow us to extract data from an app about the schedules.

Here are also some non-goals for this PR. These are left as future work:

• Extract every piece of data in the schedule. I've focused on a rough set of information that should let us visualization the most important parts.
• Provide utilities for interpreting the data. This PR is focused on just extracting the data, interpreting it comes next.
• Any sort of dot graph tools.

Solution

• Create ser/de compatible structs for representing schedule data.
• Create a function to get schedule data from an initialized Schedule.
• Create a plugin to automatically extract the schedule data for every schedule in the App.
  • Note this doesn't include other subapps, I'll also leave that to another PR.
• Make bevy_ecs return edges that build passes added.
• Make bevy_ecs return the "build metadata" to the caller, and also trigger as an event.

Testing

• Added tests!
• Added an example - it outputs a ron file. I assume its all valid.

[andriyDev]

This is currently a draft because there's a problem that edges coming from schedule build passes (e.g., auto_insert_apply_deferred) are not being extracted.

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.

[github-actions]

Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-22520

If it's expected, please add the M-Deliberate-Rendering-Change label.

If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it.

[alice-i-cecile]

LGTM now, but please do open an issue about testing all features :) Not a unique problem to this PR, and not one I want to forget about.

[kfc35]

no major logic comments (it looks good to me), just documentation

[kfc35]

iiuc, but also if this is potentially confusing to add or initialize is not used in this way, you can reject this suggestion:

Suggested change

	/// successfully, returns [`None`].
	/// successfully and has not changed since previous init, returns [`None`].

[mockersf]

This PR made the benchmarks empty_systems/0_system, run_empty_schedule/MultiThreaded and run_empty_schedule/SingleThreaded worse, but not the benches with actual systems so it's probably OK. I guess it added some overhead that disappear when you have systems in the schedule