Component lifecycle reorganization and documentation

[alice-i-cecile]

Objective

I set out with one simple goal: clearly document the differences between each of the component lifecycle events via module docs.

Unfortunately, no such module existed: the various lifecycle code was scattered to the wind.
Without a unified module, it's very hard to discover the related types, and there's nowhere good to put my shiny new documentation.

Solution

1. Unify the assorted types into a single bevy_ecs::component_lifecycle module.
2. Write docs.
3. Write a migration guide.

Testing

Thanks CI!

Follow-up

1. The lifecycle event names are pretty confusing, especially OnReplace. We should consider renaming those. No bikeshedding in my PR though!
2. Observers need real module docs too :(
3. Any additional functional changes should be done elsewhere; this is a simple docs and re-org PR.

[james-j-obrien]

This is a nit: while not strictly contradictory nor inaccurate, these three passages all seem to have been written at different points in time and so come across as inconsistent:
On RemovedComponents:

/// Note that this does not allow you to see which data existed before removal.
/// If you need this, you will need to track the component data value on your own,
/// using a regularly scheduled system that requests `Query<(Entity, &T), Changed<T>>`
/// and stores the data somewhere safe to later cross-reference.

On on_insert and on_replace:

/// # Warning
///
/// The hook won't run if the component is already present and is only mutated, such as in a system via a query.
/// As a result, this is *not* an appropriate mechanism for reliably updating indexes and other caches.

Compared to the crate root:

//! To reliably synchronize data structures using with component lifecycle events,
//! you can combine [`OnInsert`] and [`OnReplace`] to fully capture any changes to the data.
//! This is particularly useful in combination with immutable components,
//! to avoid any lifecycle-bypassing mutations.

The crate root references immutability to make the hook consistently update data structures while the corresponding method explicitly warns against using them to keep indexes up to date without mentioning immutable components. Similarly the comment on RemovedComponents makes no mention of either hooks or immutability as possible solutions and instead refers to change detection which is not mentioned in the crate root at all (Added is but Changed is not). These could just link to the module docs, my concern is that someone looks at the docs on a singular method and gets the wrong idea about what solutions are available.

[james-j-obrien]

Definitely an overall improvement and all seems accurate.

[theotherphil]

Suggested change

	The code for hooks (`HookContext`, `ComponentHook`, `ComponentHooks`) has been extracted from the very long `bevy_ecs::components` module, and now lives in the `bevy_ecs::components` module.
	The code for hooks (`HookContext`, `ComponentHook`, `ComponentHooks`) has been extracted from the very long `bevy_ecs::components` module, and now lives in the `bevy_ecs::component_lifecycle` module.

[theotherphil]

Suggested change

	/// There is two ways of configuring hooks for a component:
	/// There are two ways of configuring hooks for a component:

[theotherphil]

"Example 2" made me wonder what happened to example 1

[theotherphil]

Having recently experienced the process of grep-ing around trying to find the relevant pieces: this is much better!

[Bleachfuel]

Why not component::lifecycle, and have the lifecycle module be a submodule of the component module?