[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.
Well, my reasoning here was that, absent separate public AssetEntityAdapter and ComponentEntityAdapter interfaces, these constants are a better fit at the interface, because EntityAdapterSupport is an implementation helper and doesn't really form part of the public api.

But admittedly, it's a little wonky because both the adapter interface and support base class are, in spirit, "ComponentOrAsset" things.

I think biting the bullet and having a separate ComponentEntityAdapter and AssetEntityAdapter interface might be the right move here, even if it results in a bit more scaffolding..