Add MSRC analyzer for Windows OS component vulnerability detection

### Current Behavior

Dependency-Track has no analyzer that queries the Microsoft Security Response Center (MSRC) API for vulnerability data. As a result, components representing Windows OS installations (e.g., from Windows
container images) receive no meaningful vulnerability analysis.

When a CycloneDX SBOM/OBOM contains an operating-system component for Windows Server 2022 with a CPE such as:
`cpe:2.3:o:microsoft:windows_server_2022:10.0.20348.2762:*:*:*:*:*:x64:*`
...Dependency-Track performs no vulnerability analysis against it, because:

1. The Internal Analyzer only matches against its own mirrored NVD/OSV data, which has incomplete coverage of Windows OS CVEs
2. No existing analyzer queries the MSRC API, which is the authoritative source for Windows security advisories and the canonical mapping between CVEs and KB patches

Organizations running legacy .NET Framework applications in Windows Server Core containers (e.g., using mcr.microsoft.com/windows/servercore) currently have no way to detect Windows OS-level vulnerabilities in Dependency-Track.

_Related: #5165 (the inverse problem — Windows-only CVEs being incorrectly applied to Linux containers — highlights that DT currently has no real Windows OS awareness in either direction.)_

### Proposed Behavior

Add a new MSRC Analyzer (MsrcAnalysisTask) that queries the public MSRC CVRF v2.0 REST API to identify unpatched CVEs in Windows OS components.

How it would work:

The MSRC API publishes monthly security update documents (CVRF format) containing CVEs, affected Windows product IDs, and — critically — a FixedBuild field specifying the exact Windows build version (e.g.,
10.0.20348.2113) in which the vulnerability was resolved.

The analyzer would:

1. Trigger on operating-system components with a Microsoft CPE (e.g., cpe:2.3:o:microsoft:windows_server_*)
2. Extract the OS build number and UBR (Update Build Revision) from the component version string
3. Query recent MSRC CVRF documents for CVEs affecting the matching Windows product
4. For each CVE, compare the container's UBR against the FixedBuild UBR — this correctly handles cumulative/rollup updates without needing to enumerate individual KB numbers
5. Surface unpatched CVEs as findings, with Vulnerability.Source.MSRC, severity from the advisory, and a reference link to msrc.microsoft.com/update-guide/vulnerability/{CVE}

Why FixedBuild UBR comparison is the correct approach:

Windows uses cumulative updates — a single monthly rollup supersedes all previous patches. Comparing the OS UBR (part 4 of the major.minor.build.ubr version) against the FixedBuild UBR from MSRC accurately
reflects whether the fix is included in the installed cumulative update, without requiring KB supersedence chain resolution.

API details:

- Base URL: https://api.msrc.microsoft.com/cvrf/v2.0/ — no API key required (public REST API)
- Returns JSON; no external library needed beyond standard HTTP client
- Monthly cadence aligns well with DT's existing cache-based analysis model

Implementation sketch (follows the pattern of SnykAnalysisTask / TrivyAnalysisTask):

- New MSRC_ANALYZER entry in AnalyzerIdentity
- New MsrcAnalysisTask extends BaseComponentAnalyzerTask implements ScanTask, Subscriber
- New MsrcAnalysisEvent
- New SCANNER_MSRC_ENABLED config property
- Wire into VulnerabilityAnalysisTask.analyzeComponents()
- I am willing to contribute this implementation as a PR

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/master/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested