Public API Simplification

Right now, there are a lot of modules exposed, and with #168 being worked on, we're about to have another one added to the mix. I personally feel like the more complicated an library API looks at a first glance, and the more types, traits, modules, etc. I see immediately, the more likely I am to look for something else to use instead. I don't want anyone to assume that the amount of items documented indicates that this is a "hacky" solution.

I think it best to start by examining the "primitives" of the library:

- components
- resources
- views
- filters

On top of these are the following "compounds":

- registry
- entity
- entities
- queries
- systems
- schedules
- world

When it comes down to it, registry, entity, and entities are all just lists of components (or lists of sequences of components, for entities). Perhaps it would be best to combine these into a single `component` module, and perhaps create them all with a `components!()` or `components_batch!()` macro? This would also enable #129 to proceed, as I have been reluctant on that feature due to not wanting to just add another component list to the mix. As was stated in that issue, a list created with `entity!()` isn't really an actual entity yet in ECS terms. It's just a list of components. The entity creation happens when it is inserted into the world container, at which point the only direct handle we have is an identifier. Perhaps the semantics of `components!()` makes more sense when inserting components into a world to *become* an entity. For what it's worth, I've seen other ECS implementations call their traits `Bundle`s or similar names.

This would leave us with `component`, `query`, `resource`, `system`, and `world` modules, cutting 3 modules out. Additionally, we would likely have one less macro for heterogeneous list definitions. This leaves more room to also import some more items into the root of the crate, such as `System`s, to make working with these common types easier.