Deprecate Yno-kind-polymorphism

[Linyxus]

Fixes #22029.

[Linyxus]

One problem I have is that after @deprecate the field in ScalaSetting, the compiler is not allowed to access the field any further (other wise a deprecation warning is issued), so in this PR we will simply ignore the value of -Yno-kind-polymorphism in the compiler. Would that bring problems?

[som-snytt]

I think this is an example of deprecating the option deprecation = Deprecation.removed() and not just the field. Then users are alerted?

@deprecated(message = "Scheduled for removal.", since = "3.5.0")
  val YoutputOnlyTasty: Setting[Boolean] = BooleanSetting(ForkSetting, "Youtput-only-tasty", "Used to only generate the TASTy file without the classfiles", deprecation = Deprecation.removed())

[Gedochao]

One problem I have is that after @deprecate the field in ScalaSetting, the compiler is not allowed to access the field any further (other wise a deprecation warning is issued), so in this PR we will simply ignore the value of -Yno-kind-polymorphism in the compiler. Would that bring problems?

Hmm... it's not really deprecation if the value is no longer respected. The resulting behaviour will be inconsistent.
However, it is a private -Y option, so we give no guarantees about it... Maybe we could straight-up remove it? EDIT: Eh, we shouldn't error on it for at least one minor, I guess. We ought to remove it before the new LTS though.
@sjrd thoughts?

[sjrd]

TBH the type system of Scala 3 just does not work without AnyKind. This flag has always been a gimmick. I suggest writing a deprecation message stating that it has no effect. And then actually error out sometime later.

[Gedochao]

BTW @WojciechMazur we should backport it to 3.7.0-RC2 when it gets merged.

[Linyxus]

ready for review :)