Support framework-dependent (flat) AL Language extension layout

[aholstrup1]

❔What, Why & How

Newer, framework-dependent AL Language extensions (for example marketplace-packaged builds) ship a flat internal layout: altool, alc, aldoc, and the analyzer DLLs all live directly under extension/bin, with no win32/linux or Analyzers subfolder. Setting such a VSIX via the vsixFile setting caused workspace compilation to fail with Could not find AL tool in the compiler folder, even though the same VSIX worked fine for container and useCompilerFolder builds (BcContainerHelper already handles both layouts).

This PR makes AL-Go's own path resolution layout-aware, mirroring how BcContainerHelper resolves these tools. Three spots assumed the nested layout and now fall back to the flat bin folder:

• Get-ALTool (CompileFromWorkspace.psm1): probes bin/win32/altool.exe (or bin/linux/altool), then falls back to the flat bin/altool(.exe).
• Get-CustomAnalyzers (CompileFromWorkspace.psm1): URL-based customCodeCops download to bin/Analyzers when present, otherwise to the flat bin.
• DownloadAlDoc (BuildReferenceDocumentation): resolves aldoc in bin/win32|linux then the flat bin.

Worth noting for reviewers:

• The aldoc fix is pre-emptive. That path is fed by the VSIX bundled in the BC artifact (not the user's vsixFile), so it is not exercised by the vsixFile scenario today, but it carried the identical latent assumption and was cheap to fix alongside.
• This does not cover built-in analyzers (CodeCop/PTECop/etc.). Those are passed to altool by shorthand name, and altool itself resolves them to <altoolDir>/../Analyzers, which is wrong for the flat layout. That is an altool bug (its shorthand resolver is inconsistent with how it resolves ${CodeCop}/custom analyzers) and is being tracked separately against the AL Language / compiler team. The fixes here are validated end-to-end up to that point: with them applied, a flat VSIX now gets past tool discovery and fails only on altool's analyzer path.

✅ Checklist

• Add tests (E2E, unit tests)
• Update RELEASENOTES.md
• Update documentation (e.g. for new settings or scenarios)
• Add telemetry

[Copilot]

Pull request overview

This PR makes AL-Go's internal AL tool path resolution layout-aware so that newer, framework-dependent / marketplace-packaged AL Language extensions — which ship a flat extension/bin layout (no win32/linux or Analyzers subfolder) — work with vsixFile-based workspace compilation. Previously such a VSIX failed with "Could not find AL tool in the compiler folder", even though container and useCompilerFolder builds already handled it via BcContainerHelper. The change mirrors BcContainerHelper's resolution by falling back to the flat bin folder in three spots.

Changes:

• Get-ALTool now probes the platform subfolder (bin/win32/altool.exe or bin/linux/altool) and falls back to the flat bin/altool(.exe); the legacy al/al.exe fallback is dropped and help text is updated to "altool".
• Get-CustomAnalyzers downloads URL-based customCodeCops to bin/Analyzers when present, otherwise to the flat bin folder; DownloadAlDoc resolves aldoc the same way.
• Adds Pester unit tests for both layouts and updates RELEASENOTES.md.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
Actions/.Modules/CompileFromWorkspace.psm1	Adds flat-bin fallback to Get-ALTool and Get-CustomAnalyzers; updates comment-based help.
Actions/BuildReferenceDocumentation/BuildReferenceDocumentation.HelperFunctions.ps1	Adds flat-bin fallback for resolving aldoc (native and .dll) on Linux and Windows.
Tests/CompileFromWorkspace.Test.ps1	New tests for flat-layout analyzer download and Get-ALTool platform/flat/missing cases.
Tests/BuildReferenceDocumentation.Action.Test.ps1	New test asserting aldoc resolves to the flat bin folder.
RELEASENOTES.md	Documents the new framework-dependent extension support.

No blocking issues were found: the logic is consistent across all three resolution sites, tests cover both nested and flat layouts on Windows and Linux, cross-platform $IsLinux usage is safe (shimmed in AL-Go-Helper.ps1 for PS5), and the help/release notes are in sync. One notable behavioral change is that the previous al/al.exe fallback in Get-ALTool is removed; this appears intentional (the help text was deliberately updated to "altool") but touches critical compiler-tool discovery.