Add incremental/speculative mode for generating ExplicitResultTypes (and other unreliable options that may break compilation)

[tribbloid]

Some options may cause scalafix to generate code that no longer compiles, e.g. In this document:

https://scalacenter.github.io/scalafix/docs/rules/ExplicitResultTypes.html

It is noted that:

rewriteStructuralTypesToNamedSubclass: .... Beware that this option may produce code that no longer compiles ...

As another example, ExplicitResultTypes may also have a tendency to generate type annotations that are widened from singleton types, dependent types and duck types, which also breaks compilation.

A simple solution would be to modify code speculatively, which uses a trial-and-error search algorithm to backtrack to part of the modification that breaks compilation:

• immediately after modifying, rebuild part of the AST and semantic DB to ensure that the outcome is equivalent to the old version.
• if this verification fails, revert modification and revert to previous AST or any kind of IR
• if the verification also fails even after reverting, find all previous changes made to the code that has affected type resolving of the current scope, and try reverting and and re-verify in inversed chronological order.

This could apply options as much as it could, even if the option is highly experimental and volatile

[bjaglin]

Such a trial-and-error strategy is used by scala3-migrate, an sbt plugin applying Scalafix patches independently using the Scalafix evaluation API so that it can verify that compilation succeeds from one iteration to another.

If we were to take a similar approach in Scalafix, I'd rather see this implemented in the same fashion within the build tool (sbt-scalafix), considering that (re)compiling & generating SemanticDB from Scalafix itself turned out to be challenging and was removed.

In any case, I wouldn't say that the implementation is simple.

[tribbloid]

Hmmm, good point, most people are already using it within the sbt plugin. Maybe all it takes is just a interactive inter-process interface that can zoom into a granular part of the semanticDB?

I'm also curious about the granularity of scala3-migrate, ideally it could also convert as much as it could and ask the user for minimal manual override. So this new mode could benefit both