Make bevy_scene usable for pure bevy_ecs serialization and deserialization

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

Not everyone using Bevy uses it for games, or uses it in a context where bevy_app controls the full game loop.

However, they still need to serialize and deserialize data from the `World`.

However, `bevy_scene` [currently](https://github.com/bevyengine/bevy/blob/cfcb6885e3b475a93ec0fe7e88023ac0f354bbbf/crates/bevy_scene/Cargo.toml#L17) requires:

- `bevy_app`
- `bevy_asset`
- `bevy_hierarchy`
- `bevy_transform`

There are two sets of problems here. First, there are a number of mandatory dependencies that can just be optional. `bevy_hierarchy` and `bevy_transform` could both be feature-flagged gracefuly. Similarly, the systems added in our plugin could just be publicly exposed.

Secondly, the serialization API is fundamentally coupled to bevy_asset: there's no lower level of abstraction exposed for others to hook into in their own asset system or just for simple synchronous file reading and writing.

## What solution would you like?

The first set of problems should be solved by adding feature flags to the offending code, making those dependencies on-by-default but optional.

The second set of problems is substantially more involved, and would involve some rearchitecture. Avoiding code duplication would be good here, but I don't immediately have a plan on how one might do that.

## What alternative(s) have you considered?

The user could fork Bevy and make these changes themselves. This is frustrating wasted work.

The user could write their own serialization strategy, based on bevy_scene. This is a complex effort: ECS world state is much more difficult to serialize than other Rust data, due to both its heterogenous typing and the existence of entity-entity links.

## Additional context

Raised by a [user on Discord](https://discord.com/channels/691052431525675048/742569353878437978/1193432185882030212). I don't have an immediate need for this (or think it's pressing), but I spent some time chewing on this problem and wanted to write up my thoughts.

Start with crates/bevy_scene/Cargo.toml and the bevy_scene plugin and serialization APIs described in the issue. Trace their dependencies on bevy_app, bevy_asset, bevy_hierarchy, and bevy_transform, then identify the existing systems that could be exposed. Done means optional feature flags support pure bevy_ecs use and a lower-level serialization path can work without bevy_asset, without duplicating the core implementation.

Written by the indexing model from the issue text.