changes the order of whitebox typechecks. yes, again.

My first attempt at SI-6992 was about having whitebox expansions first
typecheck against outerPt and only then verify that the result is compatible
with innerPt.

That was a nice try, but soon after it went live in 2.11.0-M8, we've got
multiple reports with problems - both shapeless and then in a week specs2
started having issues with their whitebox macros.

In shapeless, typecheck against outerPt screwed up type inference, which
was more or less fixable by explicit type annotations, so I decided to
wait a bit before jumping to conclusions.

However, in specs2 the problem was more insidious. After being typechecked
against outerPt, expansions were being implicitly converted to a type
that became incompatible with innerPt. This revealed a fatal flaw of the
implemented approach - if allowed to typecheck against outerPt first,
whitebox macros could never be robust.

Now realizing that "outerPt > innerPt" doesn't work, I nevertheless wasn't
looking forward to rolling that back to "innerPt > outerPt", because that
would revive SI-6992 and SI-8048 that are highly unintuitive, especially
the latter one.

Therefore, this commit combines the permissiveness of "... > innerPt"
approaches with the robustness of "innerPt > outerPt", introducing
"WildcardType > innerPt > outerPt".
SI-8226 Deduplicate Scala's Tokens and JavaTokens
SI-7475 Refactor findMember computation into a class

This affords us:

  - a better chance to share code with `findMembers` again
  - the ability to break up the logic into smaller methods for
    scrutability and JIT-tability.

The cost is the use of the heap rather than the stack for the
working area of the computation. But I didn't notice a difference
between `locker.lib` and `quick.lib` after this change.

I've left the old implementation in place with an assertion to
verify identical results. In the next commit, this stepping stone
will be removed, and we'll update `findMembers` to share the code.

Some problem areas have been highlighted and will be addressed
after the refactoring phase is complete.
SI-7475 findMember and findMembers: estranged no more

Swathes of important logic are duplicated between `findMember`
and `findMembers` after they separated on grounds of irreconcilable
differences about how fast they should run:

    d905558 Variation #10 to optimze findMember
    fcb0c01 Attempt #9 to opimize findMember.
    71d2ceb Attempt #8 to opimize findMember.
    77e5692 Attempty #7 to optimize findMember
    275115e Fixing problem that caused fingerprints to fail in
    e94252e Attemmpt #6 to optimize findMember
    73e61b8 Attempt #5 to optimize findMember.
    04f0b65 Attempt #4 to optimize findMember
    0e3c70f Attempt #3 to optimize findMember
    41f4497 Attempt #2 to optimize findMember
    1a73aa0 Attempt #1 to optimize findMember

This didn't actually bear fruit, and the intervening years have
seen the implementations drift.

Now is the time to reunite them under the banner of `FindMemberBase`.

Each has a separate subclass to customise the behaviour. This is
primarily used by `findMember` to cache member types and to assemble
the resulting list of symbols in an low-allocation manner.

While there I have introduced some polymorphic calls, the call sites
are only bi-morphic, and our typical pattern of compilation involves
far more `findMember` calls, so I expect that JIT will keep the
virtual call cost to an absolute minimum.

Test results have been updated now that `findMembers` correctly
excludes constructors and doesn't inherit privates.

Coming up next: we can actually fix SI-7475!
SI-7475 Private members are not inheritable

It turns out `findMembers` has been a bit sloppy in recent
years and has returned private members from *anywhere* up the
base class sequence. Access checks usually pick up the slack
and eliminate the unwanted privates.

But, in concert with the "concrete beats abstract" rule in
`findMember`, the following mishap appeared:

    scala> :paste
    // Entering paste mode (ctrl-D to finish)

    trait T { def a: Int }
    trait B { private def a: Int = 0 }
    trait C extends T with B { a }

    // Exiting paste mode, now interpreting.

    <console>:9: error: method a in trait B cannot be accessed in C
           trait C extends T with B { a }
                                      ^

I noticed this when compiling Akka against JDK 8; a new private method
in the bowels of the JDK was enough to break the build!

It turns out that some finesse in needed to interpret SLS 5.2:

> The private modifier can be used with any definition or declaration
> in a template. They are not inherited by subclasses [...]

So, can we simply exclude privates from all but the first base class?
No, as that might be a refinement class! The following must be
allowed:

    trait A { private def foo = 0; trait T { self: A => this.foo } }

This commit:

  - tracks when the walk up the base class sequence passes the
    first non-refinement class, and excludes private members
  - ... except, if we are at a direct parent of a refinement
    class itself
  - Makes a corresponding change to OverridingPairs, to only consider
    private members if they are owned by the `base` Symbol under
    consideration. We don't need to deal with the subtleties of
    refinements there as that code is only used for bona-fide classes.
  - replaces use of `hasTransOwner` when considering whether a
    private[this] symbol is a member.

The last condition was not grounded in the spec at all. The change
is visible in cases like:

    // Old
    scala> trait A { private[this] val x = 0; class B extends A { this.x } }
    <console>:7: error: value x in trait A cannot be accessed in A.this.B
           trait A { private[this] val x = 0; class B extends A { this.x } }
                                                                       ^
    // New
    scala> trait A { private[this] val x = 0; class B extends A { this.x } }
    <console>:8: error: value x is not a member of A.this.B
           trait A { private[this] val x = 0; class B extends A { this.x } }
                                                                       ^
Furthermore, we no longer give a `private[this]` member a free pass
if it is sourced from the very first base class.

    trait Cake extends Slice {
      private[this] val bippy = ()
    }

    trait Slice { self: Cake =>
      bippy // BCS: Cake, Slice, AnyRef, Any
    }

The different handling between `private` and `private[this]`
still seems a bit dubious.

The spec says:

> An different form of qualification is private[this]. A member M
> marked with this modifier can be accessed only from within the
> object in which it is defined. That is, a selection p.M is only
> legal if the prefix is this or O.this, for some class O enclosing
> the reference. In addition, the restrictions for unqualified
> private apply.

This sounds like a question of access, not membership. If so, we
should admit `private[this]` members from parents of refined types
in `FindMember`.

AFAICT, not too much rests on the distinction: do we get a
"no such member", or "member foo inaccessible" error? I welcome
scrutinee of the checkfile of `neg/t7475f.scala` to help put
this last piece into the puzzle.

One more thing: findMember does not have *any* code the corresponds
to the last sentence of:

> SLS 5.2 The modifier can be qualified with an identifier C
> (e.g. private[C]) that must denote a class or package enclosing
> the definition. Members labeled with such a modifier are accessible
> respectively only from code inside the package C or only from code
> inside the class C and its companion module (§5.4).
> Such members are also inherited only from templates inside C.

When I showed Martin this, he suggested it was an error in the
spec, and we should leave the access checking to callers of
that inherited qualified-private member.
SI-7475 Address review comments in FindMembers

  - comment the cases in `isNewMember`
  - check both sides for privacy (doesn't influence behaviour of
    any tests, but it means that method can be understood without
    understanding the order of traversal of members.)
  - hoist `findAll`
  - break out of the loop in `FindMembers` as soon as we determine
    that the candidate member is matched by an already-found member
    and can be discarded.
SI-8167 readLine shold flush output before reading input

As reported on scala-user:

> Using `scala.Predef.readLine(text: String, args: Any*)`
> on Windows causes strange behavior. If I am leaving some
> part of `text` unforced to be flushed (say, "---\nEnter new
>  expression >") then "Enter new expression >" flushed only
> after Enter press. Still, it works fine on Ubuntu and (seems like)
> on MacOS.
>
> My workaround is to force `java.lang.System.out` (that readLine
> depends on to write welcome string) to flush output like
> "---\nEnter new expression >\n".
SI-5994 battling implicits for String.lines

Deprecated ProcessBuilder's lines method and renamed it lineStream.

stream was another possibility, but that seemed more likely to cause conflicts.

streaming was also tried, but feedback was in favor of lineStream.

Also updated tutorial in ProcessBuilder.

I am sure this will break some tests, but because of the name conflict it's hard to be sure where they are.  So Jenkins gets to find the problems for me.

Changed name to lineStream.
Merge pull request #3504 from gkossakowski/readline-flush

 readLine shold flush output before reading input
Merge pull request #3456 from soc/SI-8226

SI-8226 Deduplicate JavaTokens/ScalaTokens
Tweak parser entry point for pq

Previously pq used pattern1 which required parens to be used in
alternative pattern. This commit tweaks it to allow pq"a | b"
syntax. Also adds some tests for alternative syntax.
Merge pull request #3505 from densh/topic/pq-entry

Tweak parser entry point for pq""
Merge pull request #3495 from xeno-by/ticket/8209

changes the order of whitebox typechecks. yes, again.
Add a great test case.

Created to convince moors that certain code should compile, it
wound up flushing out some quite nutty behavior. Some day this
will compile rather than having an 11-failure checkfile.
Revert "SI-1786 incorporate defined bounds in inference"

Have to revert because the stricter bounds that it inferred break e.g., slick.
(Backstop for that added as pos/t1786-counter.scala, as minimized by Jason)
Worse, the fix was compilation order-dependent.

There's a less invasive fix (SI-6169) that could be generalized
in `sharpenQuantifierBounds` (used in `skolemizeExistential`),
but I'd rather not mess with existentials at this point.

This reverts commit e28c3edda4dd405ed382227d2a688b799bf33c72.

Conflicts:
	src/compiler/scala/tools/nsc/typechecker/Typers.scala
	test/files/pos/t1786.scala
Merge pull request #3508 from paulp/pr/great-test

Add a great test case for SI-764, which hopefully one day will compile.
Merge pull request #3454 from Ichoran/issue/5994

SI-5994 battling implicits for String.lines
Merge pull request #3509 from adriaanm/revert-t1786

Revert "SI-1786 incorporate defined bounds in inference"
Merge pull request #3503 from adriaanm/rebase-3440

SI-7475 Private members aren't inheritable, findMember overhaul
SI-261 private vals in traits depend on composition order

Fix for SI-7475 in #3440 took care of this one.

I nixed the old (redundant) test cases and replaced by a single run/ test,
which didn't compile until.