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.
Merge pull request #3503 from adriaanm/rebase-3440

SI-7475 Private members aren't inheritable, findMember overhaul