[NEXUS-7519] Part 2 of 2: CRUD for Components & Assets

This is part 2 of 2 for
https://issues.sonatype.org/browse/NEXUS-7519

This creates and implements the ComponentStore interface in nexus-component-services, assuming a single BlobStore per Nexus node for now. This new interface is expected to be the primary one against which component/asset CRUD and query operations are done by views in NX3.

Notable changes on this branch:
* The "asset" storage class is now abstract, like "component". On further thought, I concluded that having per-format storage subclasses of Asset would lead to better schema evolvability.
* ComponentEnvelope is now in the model package and is parameterized by Component and Asset class.
* Some refactoring of the adapter package to make the class hierarchy more sane.
* In addition to the new 8 CRUD-style operations, the ComponentStore interface has taken over the responsibilities previously described by the now-deleted MetadataQueryService; these functions are very closely related at an implementation level, and it is expected that most clients will want some access to Query *and* CRUD capabilities anyway, so this simplifies things for them.
I may not see the big picture, but my gut is nagging me that there's an unnecessary coupling between the component and the asset's entity adapters. Wouldn't it make sense to separate AssetEntityAdapterSupport and ComponentEntityAdapterSupport? Then we wouldn't have the apparent mirroring between `getBaseComponentStorageClass` and `getBaseAssetStorageClass`, and the resulting if/else logic in `EntityAdapterRegistryImpl#registerAdapter`.