allow ordering systems registered in computed and source state transition events

## What problem does this solve or what need does it fill?

- If a source state changes a computed state, transition events for both transitions will be triggered
- however the order in which they trigger cannot be configured
- therefore transition systems which should run after each other but trigger in different transitions which can happen at the same time don't work half the time

## example
i have a source state containing jump and fall which when computed give the computed state air variant (as opposed to ground)
(transitions between jump and fall variants and any other new air states don't trigger transitions in the computed state which is great)
on entering the air state i set air velocity based on ground velocity (ground velocity has no y component) and on jumping i skew this based on the ground normal
```rust
app.add_systems(OnEnter(T::Air), air::transfer).add_systems(OnEnter(M::Jump), jump::skew)
```
- skewing should act on the air velocity after setting so should run after
- but arbitrarily it runs before because the schedule labels are different
- system ordering e.g `.before` doesn't work here because they're in different schedule labels

## What solution would you like?

The OnEnter, OnExit and OnTransition types should only indicate how the systems are triggered **not the order they are triggered in**
I think unifying all state transition events under one label and using run conditions like we already do with states would be the best solution
so something like
```rust
app.add_systems(Transition, (air::transfer.run_if(transition(OnEnter(T::Air)), jump::skew.run_if(transition(OnEnter(M::Jump))).chain())
```
or
```rust
app.add_systems(Transition, (air::transfer.run_if(entering(T::Air)), jump::skew.run_if(entering(M::Jump))).chain())
```
although the run condition is schedule specific which might be confusing not sure on the stance for that so maybe
```rust
app.add_transitions((OnEnter::new(T::Air, air::transfer), OnEnter::new(M::Jump, jump::skew)).chain())
```
which adds the run condition under the hood - there's probably plenty of alternate solutions

## What alternative(s) have you considered?
in this case this works but also defeats the point of the state infrastructure
```rust
.add_systems(OnEnter(T::Air), (air::transfer, jump::skew.run_if(in_state(M::Jump))).chain())
```
and in more complex cases this will continue to grow more convoluted

Start by tracing the OnEnter, OnExit, and OnTransition entry points used by add_systems, focusing on how source and computed state transitions are scheduled. Compare the proposed unified Transition and run-condition approaches with the current state infrastructure. Done means transition systems from different labels can be explicitly ordered, with coverage for simultaneous source and computed state changes.

Written by the indexing model from the issue text.