Add -Yexperimental setting

[odersky]

We have a persistent issue that experimental code cannot be easily used. Nobody outside a small expert circle seems to know how to specify a nightly compiler in their workflow. With the tooling we have it's just not practical.

That leaves adding @experimental annotations to all code accessing experimental features, which is clumsy and boilerplatey. We have exempted ourselves from all that hassle since all files in dotty/tests are exempted from experimental checking. But we should eat our own dogfood! (and conclude that it is indigestible)

For quick experimentation it would be much better if we had a -Yexperimental setting as a complement to -Yno-experimental. We only need to make sure that -Yexperimental then generates only experimental code. This could be done by either having the compiler add the @experimental annotation to the Tasty of all toplevel classes or by making the generated Tasty version an unstable one. I am not sure which of the two solutions is preferable.

See #17922 for previous discussions.

[Gedochao]

We may want to look at this in tandem with #19693

[nicolasstucki]

If we add this flag we should also add it to the TASTy attributes. This will allow us to identify if a class was compiled using experimental mode. This will be indispensable to identify published build that may have problems due to experimental features enabled. It might also be used by tool to warn or disallow publishing if the artifact was compiled with experimental.

If we add the experimental attribute to TASTy, it should be present if -Yexperimental is enabled or if the compiler is a nightly/snapshot (not sure if RCs should be included or not).

[nicolasstucki]

If we have the -Yexperimental flag we might not need -Yno-experimental. We could state that no compiler is under experimental mode unless the -Yexperimental flag is used. This flag would be added in the compilation tests to have the current behavior, except in the tests that currently have the -Yno-experimental.

[odersky]

If we add this flag we should also add it to the TASTy attributes.

I agree this would make sense. But could we not alternatively rely on simply wrapping toplevel classes with the @experimental annotation in the Tasty files? And what are the tradeoffs between the two solutions?

[bishabosha]

Note that since 3.4.0 we now have a config object which injects the tasty version to use into the TastyHeaderUnpickler, this would make it relatively simple to check a flag and bump the TASTy version appropriately - we would then need to be consistent in how the nightly tasty version relates to the stable version

[lrytz]

What's the difference between this proposal and #18571?

[odersky]

My mistake. I somehow overlooked it in the settings (probably because I looked for -Yexperimental, but in fact it's -experimental, which makes more sense anyway). We are good then for this part. We should still evaluate whether we want to drop the nightly exception altogether. @nicolasstucki can you file a different issue for that?

[nicolasstucki]

Follow-in #19708