combine bevy_ecs and bevy_hecs crates. rename XComponents to XBundle

[cart]

This combines the bevy_ecs and bevy_hecs crates for a nicer project structure. For clarity, I have also renamed all "component bundles" to use the XBundle convention instead of XComponents. Ex: PbrComponents is now PbrBundle.

This of course makes (eventually) consuming hecs upstream directly harder, but we've diverged so much at this point that I'm pretty sure reconciling the two code bases is too hard to be worth it:

• we changed how query filters work (Query Filters #834), which affects both the query api and the world api
• we removed locks from the world api, which would likely be overly limiting for hecs upstream users. doing so prevents multiple "mutable" queries from happening without unsafe code.
• bevy's "change detection api". this one can probably be worked around by using the proposed hecs change detection api, but it would require hacks somewhere to ensure they are on every component. (the proposed hecs api is opt-in by adding a new tracking component for each component that needs to be tracked)
• our Fetch implementations are very different now. We removed borrow/release and dont return the same access type. (we now return a "QueryAccess" type)
• our query iterators are different (it might be worth comparing ours to the current hecs iterator, but I think hecs actually iterates faster than bevy for direct world access. we chose what we did for bevy system iteration performance / optimization stability)

We also have a number of (potential) planned changes:

• adopting a safe archetype api (https://github.com/cart/bevy/tree/archetype_rework) ... not super sold on this one, but its a possibility
• zicklag's dynamic systems/components (Dynamic Systems and Components #623)
• alternative storage types (ex: to allow faster component adds/removes when that is needed)
• We're considering a rename and/or expansion of "Bundle"
• Reworking how archetypes remove components to allow iterating over removed components for a frame after the removal occurs.

Merging the crates doesn't change bevy's relationship to hecs. We will continue to direct user contributions upstream (when it makes sense) and I will continue referring to bevy_ecs as a "fork of hecs with layers on top" (which will only change if we swap out the archetype + world implementations entirely). I really like the "cross pollination" that we've got going on right now :)

I discussed this topic at length with @Ralith (the hecs creator / lead developer) and they were very much ok with the direction taken in this pr. They are also willing to try letting us re-license bevy's hecs code as MIT (so we no longer have a mix of mit and apache code). They've started discussing this with google, so we'll see if that pans out. If google agrees, we can start the process of asking each hecs contributor if they agree to license their contributions as MIT.

While we wait for licensing stuff to pan out, I'm adopting an Apache 2.0/MIT dual licensing approach. All of our bevy_ecs code (and hecs modifications) are dual licensed under MIT and Apache 2.0. All original hecs code is currently licensed exclusively under Apache 2.0. If/when the hecs code becomes MIT, we can drop the Apache 2.0 license and label everything as MIT.