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-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-8910 BitSet sometimes uses exponential memory.

Because of an off-by-one error in scala.collection.mutable.BitSet, where a
function (ensureCapacity) is passed a list length instead of an index, when
^=, &=, |=, or &~= are passed BitSets with the same internal capacity as the
set the method is being invoked on, the size of the first BitSet is needlessly
doubled.

This patch simply changes the ensureCapacity calls to pass the last index of
the list, instead of the raw length. In addition, add documentation to
ensureCapacity to try and stop something similar from happening in the future.
fix typo. s/represenation/representation
SI-4950 Add tests, looks like it has been fixed earlier
SI-8916 Fix -Ywarn-unused-import warnings
SI-8916 Further fixes with -Ywarn-unused included
SI-8916 Revert addition of -Ywarn-unused[-import]

  -Ywarn-unused-import: creates a bogues warning, see SI-7750

  -Ywarn-unused: creates a lot of noise & has bugs, see SI-7707, SI-7712
SI-8875 showCode should print all class constructor modifiers.

showCode used to print nothing when the only modifier was a change in
visibility scope (i.e. no flags but privateWithin is set).
SI-8934 Fix whitebox extractor macros in the pres. compiler

The code that "aligns" patterns and extractors assumes that it can
look at the type of the unapply method to figure the arity of the
extractor.

However, the result type of a whitebox macro does not tell the
whole story, only after expanding an application of that macro do
we know the result type.

During regular compilation, this isn't a problem, as the macro
application is expanded to a call to a synthetic unapply:

    {
      class anon$1 {
        def unapply(tree: Any): Option[(Tree, List[Treed])]
      }
      new anon$1
    }.unapply(<unapply selector>)

In the presentation compiler, however, we now use
`-Ymacro-expand:discard`, which expands macros only to compute
the type of the application (and to allow the macro to issue
warnings/errors). The original application is retained in the
typechecked tree, modified only by attributing the potentially-sharper
type taken from the expanded macro.

This was done to improve hyperlinking support in the IDE.

This commit passes `sel.tpe` (which is the type computed by the
macro expansion) to `unapplyMethodTypes`, rather than using
the `finalResultType` of the unapply method.

This is tested with a presentation compiler test (which closely
mimics the reported bug), and with a pos test that also exercises
`-Ymacro-expand:discard`. Prior to this patch, they used to fail with:

    too many patterns for trait api: expected 1, found 2
Make global-showdef a DirectTest

The test test/files/run/global-showdef.scala was outputting
to the cwd instead of the test output dir.

Good behavior is now inherited from DirectTest.

Test frameworks, of any ilk or capability, rock.