Remove `Component` trait impl from `Handle<T>`

[tim-blackbird]

Objective

Remove the Component trait implementation from Handle<T> as its usage is now considered an anti-pattern.

The move to required components has notably made porting error prone both internally and for the code of early adopters. Due a lack of errors on the usage of high-profile but now no longer relevant Handle components like Handle<Mesh> and Handle<StandardMaterial>.

[benfrankel]

This will also resolve #14124 (migrating entirely to Handle-as-field).

[tim-blackbird]

I thought I remembered there being an issue related to this already :)

I haven't created an issue for Handle<Image> since the sprite migration to required components is well on it's way

[mgi388]

@tim-blackbird I think the new handle wrapper components need to be registered in the type registry. I tried locally myself changing one of my own Handle<Foo>s to FooHandle<Foo> and confirmed in egui inspector if we don't app.register_type::<FooHandle>(), then you cannot inspect the component.

Separately, I was also wondering if the engine should have a macro for this boilerplate?

bevy/crates/bevy_animation/src/graph.rs

Lines 133 to 149 in 700123e

	impl From<Handle<AnimationGraph>> for AnimationGraphHandle {
	fn from(handle: Handle<AnimationGraph>) -> Self {
	Self(handle)
	}
	}
	impl From<AnimationGraphHandle> for AssetId<AnimationGraph> {
	fn from(handle: AnimationGraphHandle) -> Self {
	handle.id()
	}
	}
	impl From<&AnimationGraphHandle> for AssetId<AnimationGraph> {
	fn from(handle: &AnimationGraphHandle) -> Self {
	handle.id()
	}
	}

Fine if not (or if it's not generic enough to be a macro generated for every component wrapper), or if it could come later, but I just wondered if it would help the ecosystem migrate.

[tim-blackbird]

I always forget to add those calls to register_type 😔

• Add register_type for UiMaterialHandle and AnimationGraphHandle #15784

We could potentially make use of the derive_more crate to cut down on some boilerplate