SI-7622 Phase assembly is testable

Fixing hash on nodes makes fault detection deterministic,
which aids testing.

Error messages are shortened and .dot files are dumped
automatically on faults to guard against future flakiness.
SI-7622 -Xgenerate-phase-graph is an info option

-Xgenerate-phase-graph is comparable to -Xshow-phases.

The knowledge about what is an info-only option is refactored
to Settings, which also knows which group of options comprise
the optimiser set.
SI-7622 Phases are enabled or not

Refactor the calculation of the "phase chain" a bit.
In particular, initial and terminal phases are not special
except that they must be head and last.

When done, filter for enabled phases. At this commit,
nobody claims to be disabled.

Additional sanity support of phases settings.
SI-7622 -Xshow-phases can show disabled phases

With -Ydebug, -Xshow-phases will show phases that are skipped
or not enabled.

The code is slightly refactored, so the flags table will also benefit.
SI-7622 Plugins can be not enabled

Plugins can interrogate options and declare themselves not
enabled.  The plugin itself can return false from its init
if the options do not compute.  A plugin phase component
can declare itself not enabled, same as an internal phase.

No one exploits this facility at this commit.
SI-7622 Clean Up Phase Assembly

Let optimiser components and continuations plugin opt-out
when required flags are not set.

Wasted time on a whitespace error in check file, so let
--debug dump the processed check file and its diff.
SI-7622 Scaladoc and error message polish

Restores the verbiage "run right after".
SI-7269 Rework MapLike#retains to account for desugaring change

`MapLike#retains` contains a for-comprehension that relied on the strict
`filter` by its generator. You can't, in general, iterate a mutable map
and remove items in the same pass.

Here's the history of the desugaring of:

    def retain[A, B](thiz: mutable.Map[A, B])(p: (A, B) => Boolean): thiz.type = {
      thiz.foreach {
        case (k, v) =>
          if (p(k, v)) thiz -= k
      }

Before regression (c82ecabad6~1):

    thiz.filter(((check$ifrefutable$1) => check$ifrefutable$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => true
       case _ => false
    })).withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

After regression (c82ecabad6, which incorrectly assumed in the parser that
no filter is required for isInstanceOf[Tuple2])

    thiz.withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
      case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

After the reversion of c82ecabad6, v2.10.2
This is also after 365bb2b4e, which uses `withFilter` rather than `filter`.

    thiz.withFilter(((check$q$1) => check$ifrefutable$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => true
       case _ => false
    })).withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
      case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

This commit does the same as `SetLike#retains`, and converts the map to
an immutable list before the rest of the operation.
Removing orphan check/flag files.
Limit bad advice given for erroneous pattern.

Don't suggest "_: <none>" as an alternative when the pattern
type doesn't conform to the expected type.
Restore --show-diff to partest-ack.

Looks like that issue was operator error. However partest
option --show-log really has gone missing.
SI-7810 Reflect private constructor

`JavaMirror.constructorToJava` uses `getDeclaredConstructor` now
instead of `getConstructor`.
SI-7801 Fix a nightmarish bug in Symbols#adaptInfos

The compiler-in-residence has always been a sketchy affair;
FSC and REPL offers a bounty of bugs that exploit the menagerie
of time-travel mechanisms in play for symbols' metadata (type, flags,
name and owner.) but are often cleverly masked by optimizations in
the compiler based on reference equality.

The latest: an innocuous change in Erasure:

  https://github.com/scala/scala/commit/d8b96bb8#commitcomment-3995163

means that some `ErasureMap`-s over `MethodType`-s are now true
identities (as `UnitTpe` is always the same object, whereas
`erasedTypeRef(UnitClass)` returns an different `TypeRef` each
time.)

This, in turn, enables `TypeMap#mapOver` to reuse
the existing enclosing type, and so on. On such subtleties hinge
further optimizations, such as whether or not a given phase's
`InfoTransformer` needs to add an entry in a symbols type history.

When the REPL (or FSC / Presentation Compiler) creates a new
`Run`, `Symbol#rawInfo` tries to adapt the entries in the type
history for the new run. For packages, this was taken to be a
no-op; each entry is marked as being valid in the new run and
no further action is taken. This logic lurks in `adaptInfos`.

But, when the namer enters a new symbol in a package, it
*mutates* the Scope of that package classes info `enteringTyper`.
So the later entries in the type history *must* be invalidated
and recomputed.

We have two choices for a fix:

 1) modify `Namers#enterInScope` to blow away the subsequent
    type history for the owning symbol after inserting the
    new member. Something like `owner.setInfo(owner.info)` would
    have the desired effect.
 2) Change `adaptInfos` to be more conservative when it comes
    to package classes, and retain only the oldest entry in the
    type history.

This commit goes for option 2.
Eliminate TypeTrees with null original.

This is a retry of #2801 after figuring out the range position
error. Should there be anyone out there who compiles with -Xdev,
know that this commit eliminates the 1406 errors one presently
incurs compiling src/library.

A val declared in source code receives only one tree from the
parser, but two are needed - one for the field and one for the
getter. I discovered long ago that if the val had an existential
type, this was creating issues with incompatible existentials
between the field and the getter. However the remedy for that
did not take into account the whole of the wide range of super
subtle issues which accompany tree duplication.

In particular, the duplicated tree must be given not only a
fresh TypeTree(), but that TypeTree cannot share the same
original without running afoul of range position invariants.
That's because typedTypeTree resurrects the original tree with
whatever position it has - so the "original" needs to be a
duplicate of the original with a focused position.

Should the call to TypeTree.duplicate also duplicate the original?
I think so, but I bequeath this question to others.

This commit also eliminated some duplicate error messages, because
duplicate suppression depends on the errors having the same position.

See c478eb770d, 7a6fa80937 for previous related work.
add toolbox-based utility methods to quasiquotes' tests
refactor definition tests into separate subsuite
add missing copyTypeDef utility function
rename mkAnnotationCtor into mkAnnotation
merge flagsFromBits and FlagsAsBits into FlagsRepr
use NoMods and NoFlags for reification of empty values