Add a simple method to get a ComponentId for a given Component type

[alice-i-cecile]

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

Being able to extract the ComponentId for a given component of type C is surprisingly unintuitive.

What solution would you like?

Create a public method on Component that mirrors Bundle::component_ids().

EDIT: see below; this isn't the right API. These methods should live on World and Components instead.

What alternative(s) have you considered?

1. Use world.init_component::<C>(). This is unintuitive, but basically works.
2. Convert the component type into a bundle, and call (C, )::component_ids(&mut components, &mut storages).iter().next().unwrap(). Which is more than a little cursed.

Additional context

Discovered while working on #1481 with @plof27.

[alice-i-cecile]

This should be very easy, but that code is not exactly the most approachable, so no Good-First-Issue tag here.

[GarettCooper]

I'm not clear on how this or the Bundle equivalent is supposed to be used, but I might be missing something.

I started implementing it by matching the parameters of Bundle::component_ids(), but when I went to add tests I couldn't find a way of obtaining a mut reference to a World's Components or Storages from outside of bevy_ecs. Is this intended for consumption entirely within the ECS crate, or have I just missed something? You could implement the same thing using &mut World of course, but with my limited knowledge of Bevy I believe that would limit its usage to exclusive systems or the initial setup which seems too restrictive for normal consumers of bevy_ecs (Though I don't know enough about real Bevy applications to know for sure).

Besides that, I feel like providing a Components instance to a function on the Component to extract the ComponentId is less intuitive than the other way around. Components.get_id(C::type_id()).unwrap() also has the advantage of not requiring mut Components (though that's obviously not an option if creating a ComponentId if one is already exists is a strict requirement).

[alice-i-cecile]

Thanks for investigating @GarettCooper. I think your criticisms are very fair!

After discussing this with @DJMcNab and @james7132, I think we should add two methods:

1. World::component_id::<C>() -> Option<ComponentId>. This should be read-only, and thus distinct from init_component.
2. Components::component_id::<C>() -> Option<ComponentId>.

We should not add this as a method to Component, as the correct ComponentId can vary between worlds, and the provided ComponentId must be correct for any usage of this to not violate correctness.

As part of this PR, we should add basic docs to ComponentId, and point to these constructor methods (and the one on Bundle).