Expose system accesses and filters in BRP schedule.graph

[Zeophlite]

Objective

• ScheduleData in bevy_dev_tools, and correspondingly schedule.graph in BRP, give only components related to system conflicts, not to accesses and filters, or required components - this is needed for schedule visualisation

Solution

• Add accesses, filters, and required components to ScheduleData
• Refactor tracking of components

Testing

• cargo run --example server --features="bevy_remote" in terminal 1
• curl -d'{"jsonrpc":"2.0","method":"schedule.graph","id":1,"params":{"schedule_label":"Update"}}' -X POST -H "Accept: applcation/json" -H "Content-Type: application/json" http://127.0.0.1:15702 > update3.json in terminal 2 (see migration guide)

[Zeophlite]

Note: docs copied from underlying objects, may reduce them later

[github-actions]

You added a new feature but didn't add a description for it. Please update the root Cargo.toml file.

[Zeophlite]

I've removed invertible support for now, will re-add as follow-up PR when #24771 or #24809 is merged

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

[alice-i-cecile]

LGTM once there's a migration guide :)

[alice-i-cecile]

Needs a second approval still :)

[chescock]

This seems like valuable data to expose! I'm still skeptical about exposing reads_inverted and writes_inverted in this way, but I'm willing to approve anyway if others argue that it's the right approach.

[chescock]

I'll note again that exposing a list that is either one thing or its opposite is very confusing. I'm not familiar with the BRP conventions for serializing enums, though. Would it work serialize this as separate inclusion and exclusion lists? Something like

    /// If `false`, this reads all components in `reads_included`.
    /// If `true`, this reads all components *except* those in `reads_excluded`.
    pub reads_unbounded: bool,
    /// These components are *always* read,
    /// but if `reads_unbounded` then this is empty and not exhaustive.
    pub reads_included: Vec<u32>,
    /// These components are *never* read,
    /// but if `!reads_unbounded` then this is empty and not exhaustive.
    pub reads_excluded: Vec<u32>,

would be a little harder to misinterpret.

[Zeophlite]

Once #24771 or #24809 lands, I will update to match