WIP: [NX-451] first go at a normalized component abstraction

Highlights:
* Opaque types for component and asset ids to avoid overuse of strings (and limit implicit meaning)
* Components can have zero-to-many assets, which could be part of an overall archive or exploded
* API signature contains `Record` type from `nexus-componentmetadata` for general metadata access
* Module is `components/nexus-componentbase` for now, need to find proper location for these types
* Prefer immutable types without set methods, thinking any modification should go through a service?
   Something like `componentService.addAsset(component, asset);` as it should make managing concurrency easier
From a Java API perspective, I think all we really need is a way to get the Record that corresponds to a given Component. The relationship between a metadata record and a component could be persisted in a few ways: as an inline field, as a separate ODocument referred to by the Component Record, or as a separate ODocument that refers back to the Component Record...but regardless of how, if we expect callers to be able to work directly with Record objects anyway, I don't see the danger in allowing them to start with a Record representing the Component itself. It seems like they could "follow their nose" to related metadata of interest after determining the "format" of the Component.