After a number of experiments, I think this PR now represents the more-or-less easiest model to deal with the set of compromises required to support SPDX 3 inheritance and other features in go.

Some notes:

• 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, and due to this chicken-and-egg problem between creation info and agent, where both are required and both reference each other, there is a constructor to help
• all SPDX elements must have an spdxId; this happens automatically prior to serialization
• it could be possible to have multiple SPDX document objects in the same json document but this is prohibited by the spec, only the first will be returned
• there are 2 ways to interact with the data: directly accessing structs and using interfaces. When creating documents/constructing objects, it's much more convenient to directly construct them in a familiar go struct syntax but due to the object inheritance, accessing documents is done predominantly through interfaces
• due to the way much of this all works, it is most correct to have every minor version of SPDX 3 present, since every field ID changes. There could be some workarounds, but I have not implemented them here
• no conversion backwards from v3 to v2 is implemented

Very basic example usage:

import spdx "github.com/spdx/tools-golang/spdx/v3/v3_0_1"

d := spdx.NewDocument(spdx.ProfileIdentifierType_Software, "ADocumentName",
		&spdx.SoftwareAgent{Name: "some-tool"},
		&spdx.Tool{Name: "some-tool"})

sbom := &spdx.SBOM{}
d.RootElements = append(d.RootElements, sbom)

pkg := &spdx.Package{
  Name: "a-package-name",
}

file := &spdx.File{
  Name: "a-file-name",
}

sbom.RootElements = append(sbom.RootElements, pkg, &spdx.Relationship{
  Type: spdx.RelationshipType_DependsOn,
  From: pkg,
  To: spdx.ElementList{ file },
}