Consider Removing the TypeUlid Requirement for Components and Resources

[zicklag]

Right now bones makes heavy use of the TypeUlid trait to identify types uniquely apart from their unstable Rust TypeIds.

I'm realizing, though, that it might be more appropriate to take the approach used by Bevy for non-Rust types, which is to require all components and resources to be registered with the world, at which point they are given a ComponentId or a ResourceId.

Additionally, at registration, I think we would allow specifying a type path of sorts, that would look like a Rust module path probably.

When registering a type, you provide it's layout and its module path, and it would fail to register if you had already inserted a type with the same module path.

The module paths give us a much more explanatory way to reference the types in future scripting APIs, too, because otherwise we would be using the ULID, which has absolutely no correlation to the actual type being referenced.

Finally, this would make it much easier to use components in Rust, because we don't have to add a TypeUlid to everything.

Luckily, this change wouldn't really break any existing code. It would just remove the requirement to have a TypeUlid. We'd have to try it out in the codebase, though, just to make sure we're not using TypeUlids in some context where a pre-registered component/resource ID isn't going to work very well, but I think we'd be fine.

[zicklag]

Fixed in #132.