`App::configure_sets` should work the same way as `.before` and `.after`

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

[`configure_sets`](https://docs.rs/bevy/latest/bevy/app/struct.App.html#method.configure_sets) takes an `impl [IntoSystemSetConfigs](https://docs.rs/bevy/latest/bevy/ecs/schedule/trait.IntoSystemSetConfigs.html)` as its argument.

[`before`](https://docs.rs/bevy/latest/bevy/ecs/prelude/trait.IntoSystemConfigs.html#method.before) and similar methods take an [`impl IntoSystemSet`](https://docs.rs/bevy/latest/bevy/ecs/schedule/trait.IntoSystemSet.html).

Functionally, these are identical, except that system-type labels (e.g. `my_system`) don't work with the former.
This distinction is deeply unclear to users, who will simply get confused and frustrated about why the "obvious" thing doesn't work.

## What solution would you like?

Swap to using `IntoSystemSet` everywhere and unify the APIs.

This is both more consistent for users, and simpler to maintain, as we no longer need to maintain this distinction.

## What alternative(s) have you considered?

I encountered this in the context of attempting to order `apply_state_transition` systems relative to each other. Because they don't expose a public label, I can't do this directly.

However I *could* create a dummy system which does nothing, and order it relative to the two systems I actually care about, thus inducing a transitive ordering.

This is a dumb workaround: we're not actually protecting users in any meaningful way.

## Additional context

If I recall correctly, @maniwani was originally opposed to being allowed to configure system-type sets due to... concerns around being deliberate about public surface area for configuration?

Ultimately while I do think that's a reasonable concern, I don't think it's worth the inconsistencies and frustration for users here.

Start by comparing App::configure_sets with the IntoSystemConfigs, IntoSystemSetConfigs, and IntoSystemSet APIs linked in the issue. Trace how system-type labels are accepted by the scheduling configuration methods, then verify that configure_sets supports the same inputs and that the APIs no longer maintain an unnecessary distinction.

Written by the indexing model from the issue text.