track `LanguageFeatures.SupportsFeature` calls in compilation/type checking environment

It occurs to me that calls to `LanguageFeatures.SupportsFeature` are extensively used in the context of emitting errors, and that using new constructs in older codebase lead to confusing error message.

https://github.com/dotnet/fsharp/blob/75cd8c7a3925cfb15cc03afcac243903fef20800/src/Compiler/Facilities/LanguageFeatures.fs#L221-L224

```fsharp
{ new obj() with override _.ToString() = "a" }
```

with lowest language version, this prints

> Error FS0010 : Unexpected symbol '.' in member definition. Expected 'with', '=' or other token.

Cons:
* The user doesn't have guidance that such error is fixed by switching language version
* beside manual efforts in handwriting analyzers and code fixes that perform the same logic as in the compiler, to suggest adjustments, and adding more effort to improve the messages that are raised in the "feature not supported" branch, we can't really palliate to this comprehensively, without constant efforts that won't occur

Solution:
* keeping track in some way of the calls to `LanguageFeatures.SupportsFeature` in the compilation/type checking environment, and annotating the error messages in some way, so that the compiler would print a final message guiding user to try upgrading language version
* the same could keep track of warnings that would suggest code can't be upgraded to language version (such as https://github.com/fsharp/fslang-suggestions/issues/1335#issuecomment-1809588063), to avoid misguiding the user

Side effects:
* analyzer, code gestures/actions, etc. could also piggy back on the information generated by such detailed tracking for more "F# code I like" goodness
* we could fix language version in fsproj by default, which makes the language a bit safer in context of upgrades, and opens possibilities to evolve FSharp.Core
* more backward compatibility flexibility overall

Extra considerations:
* How can library leverage LanguagesFeature checks, to provide language version specific warnings/diagnostic, restrict access to members, etc.?
* can this be motivator for some support of coeffect / algebraic effect, so the implementation in the compiler is natural / not something to constantly keep track of manually?

related: #1103, #16219