handle CycloneDX application componentType

[noqcks]

What would you like to be added:

For this PR #2143 dependency tree parsing is being added for .NET dependencies. This creates a root pkg for the application. The problem I found that the componentType being output in CycloneDX for the root pkg is a library, while it should be an application.

These are the lines that handle the componentType creation for the CycloneDX format.

Here's an example of what TestLibrary.deps.json looks like for a dotnet project in the syft test-fixtures showing that certain deps would be a application in the CycloneDX format, while others would be a library.

  "libraries": {
    "TestLibrary/1.0.0": {
      "type": "project",
      "serviceable": false,
      "sha512": ""
    },
    "AWSSDK.Core/3.7.10.6": {
      "type": "package",
      "serviceable": true,
      "sha512": "sha512-kHBB+QmosVaG6DpngXQ8OlLVVNMzltNITfsRr68Z90qO7dSqJ2EHNd8dtBU1u3AQQLqqFHOY0lfmbpexeH6Pew==",
      "path": "awssdk.core/3.7.10.6",
      "hashPath": "awssdk.core.3.7.10.6.nupkg.sha512"
    },

How should we think about this? Should there be an additional field in pkg.Package?

There is already a Type being set on a dotnet pkg, but this doesn't abstract well to the CycloneDX format.

	DotnetPkg               Type = "dotnet"

Perhaps adding a ComponentType to a package? This is something that's technically tied to CycloneDX right now, but can be generalized for other SBOM output formats in the future?

type Package struct {
            ...
	ComponentType ComponentType    `hash:"ignore" cyclonedx:"type"`     // the type of component this package represents (e.g. library, application, framework, etc)
            ...
}

type ComponentType string

const (
	ComponentTypeApplication ComponentType = "application"
	ComponentTypeLibrary     ComponentType = "library"
)

I created a draft PR around this new ComponentType field to show how it would be used to connect a root component to its applications. #2146

The same is true for the rootPkg in any ecosystem, but just using .NET as an example.

Why is this needed:

Accurate representation of dependency trees in CycloneDX.

Additional Information:

• This type of work is needed for this guac issue to be resolved.
• An explanation of direct/indirect deps in CycloneDX [Dependency Graph] How to identify direct / indirect dependencies CycloneDX/specification#33 (comment)

[kzantow]

I think the best solution here is to add the appropriate field to the DotnetDeps metadata instead of the main syft package, here: https://github.com/anchore/syft/blob/main/syft/pkg/dotnet.go#L4-L10