SI-8871 Fix specialization under REPL / FSC

The transformation of applications to specialized methods
relies on the owner of said method having had the specialization
info transform run which stashes a bunch of related data into
per-run caches such as `SpecializeTypes#{typeEnv}`.

Recently, we found that per-run caches didn't quite live up
to there name, and in fact weren't being cleaned up before
a new run. This was remedied in 00e11ff.

However, no good deed goes unpunished, and this led to a
regression in specialization in the REPL and FSC.

This commit makes two changes:

  - change the specialization info tranformer to no longer
    directly enter specialized methods into the `info` of whatever
    the current phase happens to be. This stops them showing up
    `enteringTyper` of the following run.
  - change `adaptInfos` to simply discard all but the oldest
    entry in the type history when bringing a symbol from one
    run into the next. This generalizes the approach taken to
    fix SI-7801. The specialization info transformer will now
    execute in each run, and repopulate `typeEnv` and friends.

I see that we have a seemingly related bandaid for this sort
of problem since 08505bd4ec. In a followup, I'll try to revert
that.
SI-5583 Remove the workaround for specialization bug

08505bd added a workaround for an undiagnosed interaction
between resident compilation and specialzation. This is no
longer needed after the previous commit.
SI-6613 Make Java enums work in FSC / REPL

We needed to hop from the enum's owner to its companion
module in an early phase of the compiler.

The enclosed test used to fail when this lookup returned
NoSymbol on the second run of the resident compiler when
triggered from `MixinTransformer`: the lookup didn't work
after the flatten info transform. This is related to the
fact that module classes are flattened into the enclosing
package, but module accessors remain in the enclosing class.
Optimize tail calls to avoid findMember calls

Cache the member symbols for `Boolean.{||, &&}` per-run, rather
than look them up repeatedly.

Based on profiling the tail calls phase in the program below, which
was distilled by @rmacleod2 from the code generated by macros in
https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper

Wall clock time went from 12s to 6.5s.

```scala
object Test {
    def a(): Option[String] = Some("a")

    def main(args: Array[String]) {
        a() match {
            case Some(b1) =>
        a() match {
            case Some(b2) =>
        a() match {
            case Some(b3) =>
        a() match {
            case Some(b4) =>
        a() match {
            case Some(b5) =>
        a() match {
            case Some(b6) =>
        a() match {
            case Some(b7) =>
        a() match {
            case Some(b8) =>
        a() match {
            case Some(b9) =>
        a() match {
            case Some(b10) =>
        a() match {
            case Some(b11) =>
        a() match {
            case Some(b12) =>
        a() match {
            case Some(b13) =>
        a() match {
            case Some(b14) =>
        a() match {
            case Some(b15) =>
        a() match {
            case Some(b16) =>
        a() match {
            case Some(b17) =>
        a() match {
            case Some(b18) =>
        a() match {
            case Some(b19) =>
        a() match {
            case Some(b20) =>
                println("yay")
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
            case None => None
        }
    }
}
```
Avoid needlessly deep chains of ClonedTailContext

I believe ClonedTailContext was added to avoid the need to
mutate the Boolean `ctx.tailPos`. All other calls are forwarded
to a delegate context.

This commit tries to find a delegate context with the right
value of `tailPos` to reuse that, rather than creating a
wrapper each time we need to flip that bit.
Wider use of mapConserve and the like in TailCalls

Save the Trees!

When a subtransform is an identity, we must
strive to return the identical tree to enable the lazy part of
LazyTreeCopier. If we get this wrong in a leaf, all parents are
wastefully copied.
SI-8893 Restore linear perf in TailCalls with nested matches

Compilation perfomance of the enclosed test regressed when the
new pattern matcher was introduced, specifically when the tail
call elimination phase was made aware of its tree shapes in cd3d34203.

The code added in that commit detects an application to a tail label
in order to treat recursive calls in the argument as in tail position.

If the transform of that argument makes no change, it falls
back to `rewriteApply`, which transforms the argument again
(although this time on a non-tail-position context.)

This commit avoids the second transform by introducing a flag
to `rewriteApply` to mark the arguments are pre-transformed.

I don't yet see how that fixes the exponential performance, as
on the surface it seems like a constant factor improvement.
But the numbers don't lie, and we can now compile the test
case in seconds, rather than before when it was running for
> 10 minutes.

This test case was based on a code pattern generated by the Avro
serializer macro in:

  https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper

The exponential performance in that context is visualed here:

  https://twitter.com/dridus/status/519544110173007872

Thanks for @rmacleod2 for minimizing the problem.
Avoid wasteful array creation in backend

The iteration is only needed to side effect on `instructionList`
and `code.touched`. This commit uses an iterator and `foreach`,
rather than creating throwaway Arrays.

    % time (for f in {1..200}; do echo test/files/pos/t8893.scala; done | qscalac -Xresident)

    Before: 30s
    After : 21s
SI-3439 Fix use of implicit constructor params in super call

When typechecking the primary constructor body, the symbols of
constructor parameters of a class are owned by the class's owner.
This is done make scoping work; you shouldn't be able to refer to
class members in that position.

However, other parts of the compiler weren't so happy about
this arrangement. The enclosed test case shows that our
checks for invalid, top-level implicits was spuriously triggered,
and implicit search itself would fail.

Furthermore, we had to hack `Run#compiles` to special case
top-level early-initialized symbols. See SI-7264 / 86e6e9290.

This commit:

  - introduces an intermediate local dummy term symbol which
    will act as the owner for constructor parameters and early
    initialized members
  - adds this to the `Run#symSource` map if it is top level
  - simplifies `Run#compiles` accordingly
  - tests this all in a top-level class, and one nested in
    another class.
SI-5454 Test case for another ticket fixed by the previous commit
SI-5091 Move named-args cycle test from pending to neg

There is a typechecking cycle, and since 4669ac180e5 we now report
this in a clearer manner.

Once we change the language to unconditionally interpret an
assignent in argument position as a named argument would be the
only way to get this over to `pos`.
Update check files for -Ydelambdafy:method

Should have been done in 63207e1.
Fix t8549 under -Ydelambdafy:method

the structure of Option.class generated by delambdafy:method is
slightly different. For example, lambdas declared within Option are
not emitted as nested classes, so under delambdafy:method there's no
inner class entry for anonfun classes.

The test failed because serializing a ClassTag involves serializing an
Option. Option did not have a `@SerialVersionUID`, and the classfile
generated by delambdafy:method has a different value.

The annotation is required on the parent class (Option) as well as the
subclasses (Some / None). De-serializing a Some will fail if Option
has a different SerialVersionUID.

Relates to SI-8576. We should probably have more SVUID annotations in
the library.
Ensure closure elimination test runs under -Ydelambdafy:inline
Ensure delambafy:inline for anonymous function class javap test

https://issues.scala-lang.org/browse/SI-8898
Fix lambda names under delambdafy:method in innerClassAttribute test

This should have been done in 63207e1
[nomerge] SI-8899 Revert "SI-8627 make Stream.filterNot non-eager"

This reverts commit 9276a1205f74fdec74206209712831913e93f359.

The change is not binary compatible, See discussion on SI-8899. Making
filterImpl non-private changes its call-sites (within TraversableLike)
from INVOKESTATIC to INVOKEINTERFACE. Subclasses of TraversableLike
compiled before this change don't have a mixin for filterImpl.
SI-8711 ScalaVersion.unparse doesn't produce valid versions

There is no dot between `major.minor.rev` and `-build` in a scala
version, yet that's what unparse returns for

```
// was "2.11.3.-SNAPSHOT"
ScalaVersion("2.11.3-SNAPSHOT").unparse
```
SI-8907 Don't force symbol info in isModuleNotMethod

Test case by Jason.

RefChecks adds the lateMETHOD flag lazily in its info transformer.
This means that forcing the `sym.info` may change the value of
`sym.isMethod`.

0ccdb151f introduced a check to force the info in isModuleNotMethod,
but it turns out this leads to errors on stub symbols (SI-8907).

The responsibility to force info is transferred to callers, which
is the case for other operations on symbols, too.
SI-8900 Don't assert !isDelambdafyFunction, it may not be accurate

The implementations of isAnonymousClass, isAnonymousFunction,
isDelambdafyFunction and isDefaultGetter check if a specific substring
(eg "$lambda") exists in the symbol's name.

SI-8900 shows an example where a class ends up with "$lambda" in its
name even though it's not a delambdafy lambda class. In this case the
conflict seems to be introduced by a macro. It is possible that the
compiler itself never introduces such names, but in any case, the
above methods should be implemented more robustly.

This commit is band-aid, it fixes one specific known issue, but there
are many calls to the mentioned methods across the compiler which
are potentially wrong.

Thanks to Jason for the test case!