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-8893 Test case to show that tailrec continues to work

As suggested during code review, this test checks that
the tailcalls phase recurses appropriately below a method
that doesn and does not itself tail call. The test case is
based on the pattern of code that to trigger super-linear
performance in this transform.
SI-8893 Test tailcall transform for mix of tail/non-tail recursion

Another excellent test suggestion by Dear Reviewer.

After tail calls, the transform results in:

```
def tick(i: Int): Unit = {
      <synthetic> val _$this: Test.type = Test.this;
      _tick(_$this: Test.type, i: Int){
        if (i.==(0))
  ()
else
  if (i.==(42))
    {
      Test.this.tick(0);
      _tick(Test.this, i.-(1).asInstanceOf[Int]())
    }
  else
    _tick(Test.this, i.-(1).asInstanceOf[Int]()).asInstanceOf[Unit]()
      }
    };
```

We test this by mostly exercising the tail-recursive code path with
a level of recursion that would overflow the stack if we weren't
using jumps.
Merge pull request #4036 from retronym/topic/opt-tail-calls

SI-8893 Restore linear perf in TailCalls with nested matches