Add lint: Stutter in components, resources, events, systems

[janhohenheim]

A component named NameComponent is unnecessarily redundant, Name is much better.

[BD103]

See [my comment] in #111 (comment):

Note to self: this should probably use implements_trait() and check the structure definition not the impl.

I'm going to make this a follow-up issue. I'd rather get this merged as-is.

I did some more experimentation on this. It is far easier to lint on the impl block because it does not require dealing with generics nearly as much as linting on structure definitions. implements_trait() requires a list of GenericArg, since traits can be conditionally implemented for certain generic types and not others.

While implements_trait() is handy, and I got to learn a lot more about compiler queries and binders, it's not worth it for this specific case.

In summary: components, resources, events, and systems are all designated by their associated types. All but systems are relatively easy to check for, since I believe we can look for #[derive(Trait)] using LateLintPass::check_attribute() (that is, if #[derive(...)] is retained to the HIR).

Systems are a different kind of beast, though. What we're looking for is any function that implements SystemParamFunction, which almost has as many generics as I have fingers and toes. There's no derive, no impl Trait for MyClearAndDefiniteFunction, just a blanket implementation that makes implements_trait() difficult to use. The only other signal that we can really use is to check whether App::add_systems() was called for that type, but even that has its own issues. Unfortunately, I think that's the path we're going to have to go with.

So in summary, here's my game plan for this issue:

• Write a lint checking for stutter in components, resources, and events in one fell swoop by inspecting #[derive(...)] or impl items. It shouldn't be too difficult, and you can use Add lint: Plugin not ending in "Plugin" #111 as a reference.
• In a separate PR, write a lint for stutter in systems checking for App::add_systems() calls. It should be completely separate for now, added to the Nursery category. Once it gains enough testing (with Implement UI testing framework #125 :O and through community use), it will be merged into the previous lint.

[BD103]

Also see bevyengine/bevy#14274 for more context on naming conventions.