Run schedules where all systems take a certain Input type.

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

Ability to run schedules where all systems take a certain `In`put type, either defined explicitly as part of the system's type signature or implicitly through type inference.

## What solution would you like?

First, we need a system that takes some `In`put type. We'll use #10334 as a real use case:

```rust
fn my_system(transition: In>, ...) {
// Instead of matching over them we could register each state pair to each `OnTransition` schedule.
// But, runtime branching based on the state pair gives us more expressive power.
match (transition.from, transition.to) {
(MyState::A, MyState::B) => {
// ...
}
(MyState::A, MyState::D) => {
// ...
}
// etc...
}
}
```

Then, we need the ability to define a `Schedule(Label)` that lets us set the `In`put type:

```rust
#[derive(ScheduleLabel)] // Other derives excluded for brevity.
#[schedule(in = StateTransition) // We specify the input type we want here; it should support generics.
pub struct OnAnyTransition(PhantomData);
```

Then when we go to add the system to this new schedule, it should be properly type checked to ensure we don't add a system with the wrong `In`put type:

```rust
// Register the system defined above.
app.add_systems(OnAnyTransition, my_system);

// But this should fail to compile:
fn wrong_input_system(i: In) {}
app.add_systems(OnAnyTransition, wrong_input_system);
```

The last step is being able to run a given schedule with provided input:

```rust
// Construct our system input, which must be `Clone`able (to pass it to each system).
let transition = StateTransition { from: MyState::A, to: MyState::D };
// Pass our system input when running the system:
world.try_run_schedule_with_input(OnAnyTransition, transition);
```

## What alternative(s) have you considered?

Use a `Resource` that's temporarily available at only certain points in app flow. Problem is, that's prone to obfuscation of app logic flow, and likely easy for new Bevy devs to mess up.

## Additional context

This idea was spurred on by the "temporarily available resource" discussion in #10334.

Start by tracing the existing ScheduleLabel, In, app.add_systems, and world.try_run_schedule_with_input entry points mentioned in the issue. Compare how schedule input and system type checking currently work, then define the behavior for generic schedule labels, mismatched inputs, and cloning input across systems; the examples should compile or fail as specified.

Written by the indexing model from the issue text.