Investigate removing FAKE from the build

Motivation

The repository still bootstraps FAKE 4.64.17 to run build.fsx, via build.cmd and build.sh. Most of the build now delegates to the .NET CLI, but starting FAKE still brings in legacy Mono/MSBuild discovery and old build-only dependencies.

This is already causing maintenance friction. In #4002, GenerateHelp fails because FAKE eagerly resolves an obsolete RoslynTools.MSBuild path even though the docs script does not appear to need it. The Linux build also installs Mono primarily to execute the FAKE 4 runner.

We should decide whether FAKE can be removed from Paket's own build, and agree on a replacement path before making piecemeal changes.

Current scope

FAKE currently owns:

• target orchestration and conditional Skip* parameters in build.fsx;
• clean, restore, build, publish, test, ILRepack, checksum, icon and pack steps;
• documentation generation, including a nested FAKE invocation of docs/tools/generate.fsx;
• NuGet publishing and the older GitHub/docs release automation;
• the build.cmd <Target> / build.sh <Target> contributor interface.

There are also independent uses which should be assessed separately:

• FakeLib.dll is referenced by the integration-test project;
• a pinned FAKE globbing source file is compiled into Paket.Core and used by packaging/template APIs;
• Fake.Core.ReleaseNotes is a product dependency used by the CLI;
• many FAKE package names in tests and docs are compatibility fixtures/examples and are not build-system dependencies.

Removing the build runner therefore does not necessarily mean removing every FAKE-related reference in one change.

Proposed replacement

Prefer standard .NET and repository-native mechanisms:

1. Add a small checked-in .NET build project (F# or C#) for cross-platform orchestration, process execution, release-note parsing, file operations, ILRepack and checksums. Avoid duplicating this logic in bash and batch/PowerShell.
2. Keep thin build.sh and build.cmd wrappers so existing target-oriented contributor commands remain stable during migration.
3. Move version/package metadata that naturally belongs to the projects into MSBuild props/targets, and call dotnet restore/build/publish/test/pack directly.
4. Move CI matrix and artifact orchestration into GitHub Actions. Move releases to a dedicated workflow using GitHub Actions/gh and dotnet nuget push, rather than interactive credentials and the pinned Octokit script.
5. Run documentation generation directly with dotnet fsi (or migrate it to a small docs project), replacing its limited FAKE file/globbing helpers with System.IO.
6. Migrate the integration-test FakeLib dependency and the vendored globbing implementation independently after identifying the exact APIs and compatibility requirements.

Pure shell scripts are probably sufficient as entry points, but not ideal as the single source of cross-platform build logic.

Suggested phases

• Inventory the targets, parameters, environment variables and expected artifacts exposed by build.fsx.
• Add the new build project and implement Clean, Restore, Build, Publish, tests, merge, checksum and BuildPackage.
• Run old and new BuildPackage paths in CI and compare produced packages/artifact layout.
• Switch build.sh, build.cmd and CI to the new runner; remove the FAKE 4 build package and build.fsx.
• Migrate docs generation and release automation, preferably as separate PRs/workflows.
• Decide separately whether to replace FakeLib in integration tests, the compiled globbing source, and Fake.Core.ReleaseNotes.
• Update contributor/build documentation.

Acceptance criteria

• Linux and Windows CI build and test without using FAKE as the build runner; Mono is no longer required solely for build orchestration.
• Existing commonly used targets and skip controls have documented equivalents.
• BuildPackage produces the same expected executables, checksums and NuGet packages, with equivalent version and release-note metadata.
• The full unit and integration test matrix remains available.
• Documentation generation has a supported invocation independent of FAKE 4/MSBuild discovery.
• Package and GitHub release paths are non-interactive, token-based and documented.
• Remaining FAKE-related source/runtime/test-fixture references are explicitly documented as retained or tracked separately.

Open questions

• Should the replacement build project be F# (natural for this repository) or C# (minimal bootstrap/tooling surface)?
• Which legacy target names and command-line parameters are still used outside CI and need compatibility aliases?
• Are ReleaseDocs and ReleaseGitHub still active release paths, or can they be replaced directly by workflows?
• Is byte-for-byte artifact equivalence required, or is API/package-content equivalence sufficient?

Related: #4002

Start by inventorying targets, parameters, environment variables and artifacts in build.fsx, then compare the contributor entry points in build.cmd and build.sh. Review docs/tools/generate.fsx and the separately listed FakeLib, globbing and release-note references to determine which uses are build-runner dependencies. Done means a documented migration plan that answers the open questions and defines compatibility, artifact and CI acceptance checks.