[FEATURE]: component type "source"

## Allow listing of "source" type components

Creating SBOMs for source collections is valuable, e.g. if you (have to) provide a source code bundle for OSS components you ship in a product. To partly address this need, I previously contributed [the qualifier `arch=source` for Debian packages to the PURL specification](https://github.com/package-url/purl-spec/blob/main/PURL-TYPES.rst#deb).

SPDX provides [`primaryPackagePurpose` `SOURCE`](https://spdx.github.io/spdx-spec/v2.3/package-information/#724-primary-package-purpose-field) for such use cases. (Note that other "package purposes" closely align with CycloneDX's component types.)

A dedicated "source" component type would enable defining binaries, sources, and their [dependencies](https://cyclonedx.org/docs/1.6/json/#dependencies) elegantly within a single SBOM.

For a real world example, see our contribution to a Debian OS file system builder: [SBOM Generation for isar](https://groups.google.com/g/isar-users/c/8L-CF4BJY0I?pli=1). There, we generate both CycloneDX and SPDX SBOMs – with SPDX covering source and binary packages with their relationship, while the CycloneDX SBOM covers binary packages only due to the missing "source" component type.

## Possible solutions

I think the straightforward solution is adding "source" to the [list of possible component types](https://cyclonedx.org/docs/1.6/json/#components_items_type). This approach aligns with SPDX's model and would enable easy, lossless conversion between the formats.

## Alternatives

Alternatively, we could use the generic component type `file`, but I think sources are specific and important enough to warrant their own component type.

Currently, we work around this limitation using a property `sbomNature` in [our taxonomy](https://github.com/siemens/cyclonedx-property-taxonomy/) to indicate that all components in an SBOM are sources. However, this is confusing for both human and coded readers, and prevents proper specification of source-binary dependencies.