feat: prototype 3.0 model

[kzantow]

This PR implements one possible data model to support SPDX 3, along with functional JSON serialization / deserialization. There are sure to be some rough edges!

The easiest way to understand what usage looks like is to check out the tests -- they perform some basic document creation, along with serializing, deserializing, and re-serializing to verify the documents are the same.

A few rough edges with SPDX 3 in general seem to be:

• all elements are required to have a creation Info; this PR includes a feature during JSON serialization to set all elements creation info if it is unset, I don't know if this is a great idea but it would make things a lot easier to deal with...
• all SPDX elements must have an spdxId; I also added a way to do this prior to serialization
• it could be possible to have multiple SPDX document objects in the same json document
• having an SPDX document and an SBOM independently is somewhat confusing
• there's a chicken-and-egg problem between creation info and agent, where both are required and both reference each other, so some helper as I've implemented here would probably be good; maybe it should take different information

This PR does not add anything in the way of data validation, so it is probably pretty easy to create invalid documents. How to handle this is TBD.

This PR also does not add any conversion functionality to/from older versions of SPDX.

Feedback requested!

[kzantow]

But it's also possible to avoid the nesting by accessing properties like this.

[kzantow]

I'm just going to call out the two least desirable traits of this proposal: moderately deep inheritance heirarchies with embedding are not especially fun to work with in initializers (the other proposal/implementation also uses embedding), since you must nest embedded types like this to set the "parent" type properties.

[kzantow]

The second thing is accessing single-instance properties like this. There is no magic typing as is done with the specialized collections that could be done to add methods like rel.From.SoftwareFile(), for example. This means it's required to type assert... but because of the inheritance, you cannot type assert to *spdx.SoftwareFile, or you'll miss any subtypes, so the spdx.As function is a helper that simply switches on the type provided -- in this case *spdx.SoftwareFile switches to test for spdx.AnySoftwareFile interface, and if found calls .asSoftwareFile() to get a reference. This allows the inheritance to work properly at the expense of not really being able to do anything idiomatic here.

[kzantow]

The second thing is accessing single-instance properties like this. There is no magic typing as is done with the specialized collections that could be done to add methods like rel.From.SoftwareFile(), for example. This means it's required to type assert... but because of the inheritance, you cannot type assert to *spdx.SoftwareFile, or you'll miss any subtypes, so the spdx.As function is a helper that simply switches on the type provided -- in this case *spdx.SoftwareFile switches to test for spdx.AnySoftwareFile interface, and if found calls .asSoftwareFile() to get a reference. This allows the inheritance to work properly at the expense of not really being able to do anything idiomatic here.