Support packaging as a dotnet tool

[JamieMagee]

See https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools-how-to-create

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.2%. Comparing base (079b805) to head (0f2c6e7).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1547     +/-   ##
=======================================
- Coverage   90.2%   90.2%   -0.1%     
=======================================
  Files        423     423             
  Lines      35476   35476             
  Branches    2209    2209             
=======================================
- Hits       32021   32020      -1     
  Misses      3001    3001             
- Partials     454     455      +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull Request Overview

This PR adds support for packaging Component Detection as a .NET global tool by setting PackAsTool=true and defining ToolCommandName=component-detection in the project file.

Key changes:

• Enables the project to be packaged as a .NET global tool that users can install via dotnet tool install
• Sets the command name to component-detection for invoking the tool after installation

[Copilot]

The RuntimeIdentifiers property should not be used together with PackAsTool=true. .NET global tools are designed to be framework-dependent and cross-platform. The RuntimeIdentifiers property is for creating runtime-specific self-contained executables, which conflicts with the dotnet tool packaging model.

When dotnet pack runs with both properties set, it may create multiple RID-specific tool packages instead of a single cross-platform tool package, or the tool may not install/run correctly.

Consider one of these approaches:

1. Remove RuntimeIdentifiers from the project file and specify it only on the command line when running dotnet publish for self-contained builds (the release workflow already does this)
2. Create a separate project specifically for the dotnet tool packaging without RuntimeIdentifiers

The release workflow already specifies --runtime explicitly for self-contained builds, so removing RuntimeIdentifiers from the project file shouldn't affect those builds.

Suggested change

<RuntimeIdentifiers>win-x64;linux-x64;osx-x64;win-arm64;linux-arm64;osx-arm64</RuntimeIdentifiers>