Emit valid SARIF URIs for AL code analysis paths containing spaces (#2330)

## Why

When `ProcessALCodeAnalysisLogs` writes the SARIF file it put the raw
workspace-relative path straight into
`results[].locations[0].physicalLocation.artifactLocation.uri`. SARIF
`artifactLocation` URIs must be valid URI references, but BCApps paths
routinely contain spaces (for example `1.Setup Data/Foo.al`, `Contoso
Helpers/...`). A raw space is not a valid URI character, so
`github/codeql-action/upload-sarif` logged thousands of `'...' is not a
valid URI` warnings and alerts could fail to map back to their files.

## What

Added a small `ConvertTo-SarifArtifactUri` helper that URI-encodes each
`/`-separated path segment individually with `[Uri]::EscapeDataString`,
preserving the `/` separators. So `1.Setup Data/Foo.al` becomes
`1.Setup%20Data/Foo.al` and the path structure is unchanged.
`GenerateSARIFJson` now runs the relative path through this helper only
when writing the `uri` field; de-duplication still keys on the raw
relative path, so dedup semantics are untouched.

Verified live on a BCApps PR: after the fix, 0 `not a valid URI`
warnings.

## Changes

- `Actions/ProcessALCodeAnalysisLogs/ProcessALCodeAnalysisLogs.psm1`:
new `ConvertTo-SarifArtifactUri` function (with comment-based help),
exported from the module.
- `Actions/ProcessALCodeAnalysisLogs/ProcessALCodeAnalysisLogs.ps1`:
encode only the `uri` line in the result object.
- `Tests/ProcessALCodeAnalysisLogs.Test.ps1`: an end-to-end test
asserting the emitted `uri` is encoded (and that `/` is preserved), plus
a unit-test `Context` for the new function. Tests pass on both Windows
PowerShell 5 and PowerShell 7.
- `RELEASENOTES.md`: release note describing the fix.

## Notes

This is split out of a larger changeset into its own PR: it contains
only the SARIF URI fix, no performance/scaling change to
`ProcessALCodeAnalysisLogs` and no `trackALAlertsInGitHub`
workspace-compilation change.

---------

Co-authored-by: aholstrup1 <aholstrup1@users.noreply.github.com>