SBOM Details and Management - List of Suggested Improvements

The enhancement may already be reported! Please search for the enhancement before creating one.
Hi I have a list of enhancements that I think would really make DependencyTrack a really solid solution. For context I am currently doing work for a medical device company, and there are some recent newly drafted FDA guidelines, which while definitely not written by a security professional, have resulted in me capturing some gaps in the information available in the CycloneDX SBOMs my company is dynamically generating and sending to DependencyTrack. If you are interested in the guidance for any future R&D ideas it might spark beyond this ticket, you can find it [here](https://www.fda.gov/media/119933/download).

### Current Behavior:
1. SBOM Export: I can only export SBOMs in a JSON format, which while great for programmatical use, is still limiting. Additionally I can export these SBOMs with or without a list of OSS vulnerabilities provided by DependencyTrack.
2. Third-party integrations for components: Currently the only information that is acquired through this method, is the open-source vulnerabilities (as far as I can tell)

### Proposed Behavior:
1. Inline with DependencyTrack's ability to ingest XML SBOMs, XML support for export should be added. I had someone asking for an XML format due to it being a preferred format by the FDA.
2. Additionally, I have other people requesting the SBOM in a CSV format, which is easier to read as a human, than XML or JSON. SO it would be nice to have that as an option.
3. There are some key missing fields, which I currently have to obtain the details for myself, that are:
a. The FDA guidance refers to "manufacturer" as a required field, which with modern dependencies is referred to as Maintainer/Author Name and Email
b. Latest Version
c. Whether the current version is up-to-date (This shows in DependencyTrack but not in the SBOM export)
**_These details can be fetched at:_**
a. NodeJS via the NPM JS registry API (https://registry.npmjs.org/{PACKAGE})
b. Python via the PyPi registry API (https://pypi.org/pypi/{PACKAGE}/json)
c. Other languages would require further R&D.
4. In addition to the above, I don't have a clear way of working this out, but if a dependency is no longer maintained. I recognise this may be an existing feature in DependencyTrack, but haven't had a situation where I've had a dependency that is no longer maintained in my project to find out. If it is an existing feature, that would also be information I would want added to the SBOM upon export.
5. Option to import vulnerabilities from a third-party vulnerability scanner. I know DefectDojo supports a series of vulnerability scan reports in terms of ingesting findings, the parsers for which are found [here](https://github.com/DefectDojo/django-DefectDojo/tree/master/dojo/tools). It would be awesome if you could do something similar with a DependencyTrack project, and then have the option to choose to include either the DependencyTrack OSS vulns, or the vulns from the imported vulnerability report.
6. Inline with the above proposed changes it may make sense to have a series of drop-down boxes, as follows:
a. The first box should allow you to select the SBOM format: **SUGGESTED OPTIONS**: `json`, `xml`, or `csv`
b. The second box should allow you to select vulnerabilities, whether to include them, and from what source. **SUGGESTED OPTIONS**: `DependencyTrack OSS Vulnerabilities`, `{VULNERABILITY SCANNER NAME} Vulnerabilities`
7. Support Python packages from Conda that aren't available on PyUp. Check out `_libgcc_mutex` as it doesn't exist in PyUp, but can be found on the Anaconda site [here](https://anaconda.org/conda-forge/_openmp_mutex/).

Thanks in advance for your consideration of these features.