bevy_reflect: Update on_unimplemented attributes

[MrGVSV]

Objective

Some of the new compile error messages are a little unclear (at least to me). For example:

error[E0277]: `tests::foo::Bar` can not be created through reflection
   --> crates/bevy_reflect/src/lib.rs:679:18
    |
679 |         #[derive(Reflect)]
    |                  ^^^^^^^ the trait `from_reflect::FromReflect` is not implemented for `tests::foo::Bar`
    |
    = note: consider annotating `tests::foo::Bar` with `#[derive(Reflect)]` or `#[derive(FromReflect)]`

While the annotation makes it clear that FromReflect is missing, it's not very clear from the main error message.

My IDE lists errors with only their message immediately present:

This makes it hard to tell at a glance why my code isn't compiling.

Solution

Updated all on_unimplemented attributes in bevy_reflect to mention the relevant trait—either the actual trait or the one users actually need to implement—as well as a small snippet of what not implementing them means.

For example, failing to implement TypePath now mentions missing a TypePath implementation. And failing to implement DynamicTypePath now also mentions missing a TypePath implementation, since that's the actual trait users need to implement (i.e. they shouldn't implement DynamicTypePath directly).

Lastly, I also added some missing on_unimplemented attributes for MaybeTyped and RegisterForReflection (which you can see in the image above).

Here's how this looks in my IDE now:

Testing

You can test by adding the following code and verifying the compile errors are correct:

#[derive(Reflect)]
struct Foo(Bar);

struct Bar;

[MrGVSV]

I'm not entirely sure if I should add some to the reflection subtraits like Struct, TupleStruct, etc.

Since those aren't used as bounds in the derive macro (or almost at all really), I think the normal the trait bound `tests::foo::Foo: tuple_struct::TupleStruct` is not satisfied error message is good enough.

Thoughts here? Are they worth adding or is that overkill?

[bushrat011899]

This is definitely better wording than my original messaging, good choices! I hadn't considered the way some IDEs only show the initial error statement.