Change in F# branching strategy

### TLDR

If you are a feature contributor, nothing changes. Just keep raising PRs to main.
If you create a new `LanguageFeature`, it shall be mapped to `vNext` instead of `preview` if it is considered stable.

## Context
### Branching

This repository was using release `release/*` branches for two purposes:
1. Servicing branches for already released versions of the products (.NET SDK, Visual Studio, nugets).
2. A "future" branch for a not-yet released version of the product, the next major version of the products.

Development went via `main`, but all insertions into the products happened via the future branch.

### Alignment

The branching strategy with a future branch was not aligned with rest of .NET. This was mostly visible in the virtual mono repository for full .NET at `dotnet/dotnet`. All other components were flowing their `main` into it, but F# was flowing the future branch there.

## The Change

Starting from today, `dotnet/fsharp` gets aligned with other .NET components and will only use release branches for servicing. The `next major release` will be implicitly covered by `main`.

This means that preview versions of .NET SDK or Visual Studio will also get served by this repository's `main` and no longer a release branch. This will also speed up the feedback loop by eliminating the step of a bot merging changes from main to release branch.

### When to use servicing `release/*` branches

The servicing branches are still relevant for bugfixes that should go into servicing releases of the products (e.g. into `9.0.303` version of the .NET SDK, which is a servicing release for .NET 9).

The right branch target can be either selected upfront, or used via backporting after the change lands in `main` first.

### When is a new `release/*` branch created

`main` will always carry the meaning of next major version. Once development for that major releases freezes (let's say for .NET 10), a servicing branch for the just closed version gets created and will be open for contributions which are relevant for servicing (= bugfixing only, no new features).

## Language Features

With `main` always having the meaning of upcoming major version, all new language features can be mapped against it. The user will go trough an explicit act of using a preview version of the SDK, and will not need to also map a `LangVersion` element in the project in order to dogfood new features. The community of contributors should therefore get more testing exposure for newly introduced features.

In the event of breaking changes, the option to downgrade a project level `LangVersion` will still be there.
The `preview` language version mapping shall be still used for features that are not considered finished or stable.

### TLDR for language features
The default for users of preview .NET SDK versions changes to get all new language features without another explicit act. Before this change, users needed to BOTH download a preview SDK AND reconfigure the project.

## Fineprint

This change might affect you if you are using any repository-level automatism and relied on the existence of future-version branches. Please reach out to us if this breaks any existing use cases.