Tooling suggestion - set up a path to deprecate non-SDK style projects (classic msbuild projects)

[T-Gro]

This issue is a proposal to start planning on how to deprecate legacy, non-SDK, .fsproj project support.
This is about projects in VS (or CLI VS tools) that typically start like this and then hundreds lines of XML follow:

 <Project ToolsVersion='4.0' DefaultTargets='Build' xmlns='http://schemas.microsoft.com/developer/msbuild/2003'>

The hypothesis is that people/projects stay at those projects not because they have to, but because they can and it works.

What would be needed:

• Have good OSS candidates to test automated AI tools for conversion
• Decide on a reasonable deprecation timeline (= heads up duration)
• Figure out if and how a separate "snapshot" .vsix should be created as a fallback before the code is fully removed

Some important remarks:

• This does not mean dropping support for .NetFramework projects, even those can be migrated to SDK-style projects
• Old VS (or headless VS tools, e.g. in CI) will still keep supporting those, keeping a viable path for projects that have to be build but are no longer developed
• The already released legacy project tooling would still carry the full Visual Studio support when it comes to security releases. In the case of VS2022, that would be 10 years. (the code would be deleted from main, but still exist in the feature branch which maps to VS 2022)

I am opening the issue as a scream test.