Project reference paths with `$(SolutionDir)` end up as components

**Affected CycloneDX version**: 5.0.1.0 - 5.5.0.0

### Setup

Consider a project file (`Project.csproj`) which contains a `ProjectReference` that uses `$(SolutionDir)` in its path, as follows:
```

````

The project for which the SBOM needs to be created lives in another folder (`Applications`). We run CycloneDX as follows:
```
.\dotnet cycloneDX .\Applications\Project\Project.csproj -o ./sbom -tfm net8.0-windows --json --recursive --include-project-references
```

### Output
The SBOM output, in the "components" section, contains output similar to:
```
"components": [
{
"type": "library",
"bom-ref": "C:\\path\\to\\the\\solution\\dir\\$(SolutionDir)Common\\SomeReferencedProject\\SomeReferencedProject.csproj@undefined",
"name": "C:\\path\\to\\the\\solution\\dir\\$(SolutionDir)Common\\SomeReferencedProject\\SomeReferencedProject.csproj",
"version": "undefined",
"scope": "required"
},
...
```

Note that:
- The projects are added as components, which should not happen as far as I know. The projects should only be used to transitively trace dependencies.
- `bom-ref` and `name` somehow include both the resolved `$(SolutionDir)`, and `$(SolutionDir)` verbatim. There must be some parsing that is going wrong.

### Workaround
Using relative paths instead seems to work.

Start by reproducing the issue with the `dotnet cycloneDX` command against `Applications/Project/Project.csproj`, using `--recursive` and `--include-project-references`. Trace how the `ProjectReference` containing `$(SolutionDir)` is processed. Done means referenced projects are used for dependency tracing without becoming components, and generated `bom-ref` and `name` values contain neither the unresolved variable nor an `undefined` version.

Written by the indexing model from the issue text.