Pull Schedules::ignored_scheduling_ambiguities into a separate resource and avoid unnecessary allocation

[ItsDoot]

Objective

• Part of Extensible Schedule Graphs #20115

While it is related to the scheduling infrastructure, there is no need for ignored scheduling ambiguities to be directly co-located in Schedules. We can also avoid a clone by storing them separately.

Solution

• Moved Schedules::ignored_scheduling_ambiguities into its own Resource: IgnoredAmbiguities.
• Changed to HashSet instead of a BTreeSet; we don't have a need for ordering.

Testing

Reusing current tests.

[hymm]

Each schedule is going to produce it's own ambiguities. Shouldn't this be like HashMap<ScheduleLabel, IndexSet<ComponentId>>? or maybe a component might be better. Since you can store schedules outside of the Schedules resource and this would keep them from overwriting if they share a schedule label.

• also change it to an IndexSet because we want a stable iteration order.

[ItsDoot]

Each schedule is going to produce it's own ambiguities. Shouldn't this be like HashMap<ScheduleLabel, IndexSet<ComponentId>>? or maybe a component might be better. Since you can store schedules outside of the Schedules resource and this would keep them from overwriting if they share a schedule label.

ScheduleGraph::ambiguous_with_all and ScheduleGraph::ambiguous_with are the per-Schedule ambiguity stores, this is the global one. I'm just moving the global one outside of the Schedules resource. I can add a flag to Schedule for whether it should use the global storage or not?

[ItsDoot]

We could also do a two-tier system where each Schedule also has their own HashSet<ComponentId>, and have a flag to also fetch from the global set.

[ItsDoot]

FWIW, before and after this PR as-is, all Schedules have to adhere to the global ambiguity set. So adding an opt-out would be a new thing.

[ItsDoot]

* also change it to an IndexSet because we want a stable iteration order.

The engine itself doesn't iterate the set, and I can't find any examples on GitHub (including bevy_mod_debugdump) of people iterating the set, so I don't think we need to make it an IndexSet.