handle CycloneDX application componentType

**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](https://github.com/anchore/syft/blob/main/syft/formats/common/cyclonedxhelpers/component.go#L30-L33) 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. https://github.com/anchore/syft/pull/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](https://github.com/guacsec/guac/issues/1098) to be resolved.
- An explanation of direct/indirect deps in CycloneDX https://github.com/CycloneDX/specification/issues/33#issuecomment-653169620

Start with syft/formats/common/cyclonedxhelpers/component.go and the TestLibrary.deps.json fixture to understand the current CycloneDX component types. Review draft PR #2146 and the package model discussion, then verify that root application components and dependency libraries are represented accurately with coverage for the .NET example.

Written by the indexing model from the issue text.