bevy_world_serialization depends on bevy_camera unconditionally in 0.19

## Bevy version and features

- bevy 0.19.0
- In this case I found this from switching a cli only app to bevy replicon, which by default does use default bevy features. But I would argue world serialization shouldn't unconditionally depend on gui crates or at least should optionally depend upon gui crates based on bevy feature flags.

Ref:
https://github.com/bevyengine/bevy/blob/release-0.19.0/crates/bevy_world_serialization/Cargo.toml#L30

## \[Optional\] Relevant system information

n/a

## What you did

Describe how you arrived at the problem. If you can, consider providing a code snippet or link.

In this case just added bevy replicon which added a default bevy feature flag to a crate using:

```
bevy = { version = "~0.19", default-features = false, features = [
"libm",
"async-io",
"multi_threaded",
"bevy_log",
"async_executor",
"bevy_state",
] }
...
bevy_replicon = "~0.41";
```

This isn't really about replicon however and the fix to be clear was there, but I do want to at least bring this up as a possible issue with world serialization in the new 0.19 scene setup. I might be a weirdo using bevy for non gui application logic but I would argue non gui bevy apps might want to serialize the world in the future as well and do that without bringing in heaps of gui related bevy dependencies.

https://docs.rs/crate/bevy/latest/features#bevy_world_serialization

My workaround as a note was to just setup these features to side step the default features in bevy_replicon that caused cargo to start evaluating in all the other gui dependencies:

```
bevy_replicon = { version = "~0.41", default-features = false, features = [
"client",
"server",
] }
```

## What went wrong

- I would expect world scene serialization to take into account if a bevy application is built with ui features or not. And if not obviously only gui related serialization would be impacted. I'm not sure if that is applicable or not or if serialization directly implies ui related components.
- Around 10MiB or so of dependencies depending on platform pop up where you might not expect them to causing needless compilation and final binary bloat.

## Additional information

Should be pretty straightforward and not sure its a critical issue by any stretch of the imagination but happy to help to try fixing things if we know which top level feature flags might impact gui related serialization.

Start with the referenced crates/bevy_world_serialization/Cargo.toml feature and dependency definitions, then compare the dependency graph for the listed default-features=false configuration and for normal Bevy defaults. Determine whether GUI-related dependencies are unconditional or can follow existing Bevy feature flags. Done means world serialization does not pull those dependencies into non-GUI builds without breaking supported serialization features.

Written by the indexing model from the issue text.