Replace imports/ExternalMap with SpdxDocument

[davaya]

Issue #415 calls for clarifying the roles of Bom and SpdxDocument:

• a Bundle/Bom/Sbom lists elements that are members of a logical collection without regard to where they are serialized.
• an SpdxDocument element lists elements serialized in a payload, used to import elements from another payload.

This PR addresses logical/physical separation and the import use case by:

• deleting the ExternalMap type and the ElementCollection imports property that references it because "external" isn't a concept that applies to the logical element graph.
• adding locationHint and verifiedUsing properties to SpdxDocument to locate and verify the referenced payload.

The serialization playground has an example of one payload referencing elements carried in another payload using SpdxDocument.

[maxhbr]

isn't a Element with the list of elements a Bundle or Collection? Why not inherit from one of those?

[davaya]

In general because SpdxDocument has nothing to do with the logical model, or as Sean put it yesterday, with the "SPDX graph". When you define a Bundle element you are saying "the graph is saying something meaningful and worth remembering about this group of elements", whereas SpdxDocument is saying "if you have a payload or find it based on locationHint, you can verify the elements in it". The fact that some elements are in the same payload is not worth memorializing in the graph, particularly since the same elements can appear in different payloads in different combinations. ElementCollection is a persistent grouping, the SpdxDocument Element is purely transactional, as opposed to the SpdxDocument (payload) itself, which is a concrete persistent object itself that has meaning and is used at the physical layer, outside the graph, regardless of whether an SpdxDocument Element has ever been created to reference it.

In particular, because even ElementCollection has rootElement, which doesn't have anything to do with serialized data payloads. The payload itself must contain everything needed to understand and use it; anything in the SpdxDocument Element beyond what is needed to find and verify serialized data is just another dependency / coupling between logical and physical layers that should not exist.

Or to put it another way, if an application maintains "the graph", having done everything necessary to populate it with valid node data, every SpdxDocument Element (node) can be thown away without losing anything other than hints about where payloads were or might be found. The entire graph can be (re-)constructed from the SpdxDocuments (payloads) themselves with zero SpdxDocument Elements/nodes.

[goneall]

Finally got a chance to not only review, but think through the different scenarios. I believe these changes make sense and better represents the intent of SPDX Document and better separates the logical and physical model.

That being said, since we came up with the current model after lots (and lots) of discussion on the tech call, I'm reluctant to merge before discussing at least briefly.

I'm particularly interested in @iamwillbar and @sbarnum views on this.

[goneall]

To avoid confusion, I'm going to close this since it conflicts with our recent decision.

@davaya - we can re-open if our test of the external map proves that it doesn't work efficiently.