Reorganize system modules

[JoJoJet]

Objective

Follow-up to #8377.

As the system module has been refactored, there are many types that no longer make sense to live in the files that they do:

• The IntoSystem trait is in function_system.rs, even though this trait is relevant to all kinds of systems. Same for the In<T> type.
• PipeSystem is now just an implementation of CombinatorSystem, so system_piping.rs no longer needs its own file.

Solution

• Move IntoSystem, In<T>, and system piping combinators & tests into the top-level mod.rs file for bevy_ecs::system.
• Move PipeSystem into combinator.rs.

[alice-i-cecile]

I'd like to break up the top level mod.rs a great deal further, but this is incrementally better.

[JoJoJet]

Is there anything specific you'd like to be moved into different modules? As of this PR, mod.rs only contains items that, in my opinion, don't really make sense to be in their own files: assert_is_system, IntoSystem, In<T>, and the system_adapter module, plus a bunch of unit tests.

[alice-i-cecile]

I think the system_adapter module should be split out: it's self-contained and quite different from the rest of the internals.

[JoJoJet]

I can split it out if you'd prefer, but I don't think it's necessary. It'd be easy to move that module into a different file but I don't think there's much reason to -- that module isn't doing anything complicated or novel, it's just a relatively short list of trivial functions, similar to common_conditions which does not have its own file.

Also, this may not go anywhere, but note that I've been working on a PR that would deprecate the system_adapter module entirely and replace it with a zero-cost abstraction (which .pipe() is not).

[alice-i-cecile]

Sounds good; I'm fine to leave it alone.