[NEXUS-7657] Make rawcontent use ComponentStore

https://issues.sonatype.org/browse/NEXUS-7657

This gets rid of the direct orientdb/blobstore stuff and goes against the new ComponentStore.

Implementation note: With this change, AssetAdapters and ComponentAdapters are still registered automatically via sisu Mediators, but the storage classes are created lazily so we can be sure the requisite DatabaseInstance is initialized. However, note that we can't create them *too* late, because if a transaction is open against orient, it is not possible to make schema changes. So they are created by the new ComponentStore interface method, prepareStorage, so that components that need them to exist can request that they're created when the component initializes.  See RawBinaryStoreImpl.on(NexusInitializedEvent) for example. Together, this ensures that the underlying storage classes are created at just the right time, if needed. Making this a bit cleaner should be possible after NEXUS-7303 (support for @PostConstruct and @PreDestroy) is implemented.
@jdillon can you confirm? I interpreted the question more generally. 

Stuart, regarding your observation, yes, the current design does require using specific sub-classes of BaseComponent and BaseAsset, and there's a cost to that. We could probably avoid the need to do it, but there are a couple advantages to the current design, stemming from the fact that it results in an orient class (and thus, a separate record cluster) per component/asset type:

Scalability. Component data and indexes are automatically segregated by component type by default. So, for example adding a few million nuget records *generally* doesn't affect the performance of maven metadata access/queries.

Evolvability. Today you only want the "base" properties, but tomorrow you decide it would be good to add an a property 'foo' and an index on it for MySimpleComponentType because the view needs it.  If you started out by using a shared cluster, which other component types are also using, you now need to migrate records to another cluster in addition to adding and building the new index. You could technically get by without moving records to another cluster, but the shared class' schema definition is going to start getting pretty messy if this happens a few times.