Decouple serialization and reflection

[alice-i-cecile]

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

Reflection and serialization (specifically, serde serialization) are tightly coupled right now.

For example, Option<T>'s Reflect implementation has a Serialize trait bound.

This can make it challenging to model types that should be reflected but not serialized (e.g. for fancy ECS tricks like trait queries or editor inspection, see #3580). Additionally, this makes relying on bevy_reflect without using serde (either without any serialization or with an alternate backend) effectively impossible.

What solution would you like?

1. Lock all of the serialization code behind a serialize feature flag. serde should only be a dependency with the serde flag enabled.
2. Modify the impl_reflect_value macro to account for whether or not this feature flag is enabled.
3. Remove the serialize and deserialize trait bounds on storage types like Option and HashSet. We should ensure that these types can still be serialized if and only if the underlying values are serializable.
4. Remove the serialize method on Reflect. Instead, create a second ReflectSerialization trait that handles this, and does not return an option. This method should return a Box<dyn Serializable>, allowing users to implement this trait with their own serialization backend.

Alternatives considered

We could keep serialize as a method on Reflect. This is less useful, as being able to distinguish between serializable reflected objects and non-serializable ones at the type level is very relevant in end-user code. It also prevents us from hiding all of the serialization functionality behind a feature flag.

Additional context

Issue created for @kabergstrom, who wants to avoid serde due to excessive compilation times.

[MrGVSV]

How would this affect serializing/deserializing scenes? I’m assuming scenes will require the serde feature then, right?

[MrGVSV]

Does #5197 close this out? It made it so that we don't need T: Serialize and things like that, instead users need to manually register the serializable types like app.register_type_data::<Option<String>, ReflectSerialize>().

[alice-i-cecile]

Yep, I'm calling this closed.