Scaladoc jars should go to /api.
Remove cruft from pom.

My understanding is distributionManagement is only needed to configure
maven locally for publishing. Since we do that it ant, getting rid of it.
Improve ExecutionContext implicitNotFound and docs

It is not good practice to import a specific ExecutionContext
all over the place; we shouldn't recommend that. People should
allow callers to specify the context in most cases and only
import the context in some central location in their code.

While we are at it, add some more comprehensive docs to
ExecutionContext which will hopefully give people enough understanding
to make decisions about it.
SI-4997 deprecate StringLike.linesIterator for StringLike.lines

Deprecated.  lines is by far more consistent with the rest of the naming in the library.
PR #3233 cleanup

- `::.head` became a `val`; excessive accessor removed
- SerializationProxy moved to `object List`
Merge pull request #3467 from retronym/ticket/8030-companion

SI-8030 Restore thread safety to the parser
Merge pull request #3465 from pavelpavlov/list-head-val

PR #3233 cleanup
Merge pull request #3400 from retronym/ticket/8170

SI-8170 Fix regression in TypeRef#transform w. PolyTypes
Merge pull request #3462 from retronym/ticket/8233

SI-8233 Fix regression in backend with boxed nulls
Merge pull request #3453 from Ichoran/issue/4997

SI-4997 deprecate StringLike.linesIterator for StringLike.lines
Merge pull request #3432 from havocp/patch-1

Improve ExecutionContext implicitNotFound and docs
SI-8239 don't loop forever in ContextTrees.locateContextTree

Made loop invariant / recursion metric explicit.
Merge pull request #3457 from retronym/ticket/8228

SI-8228 Avoid infinite loop with erroneous code, overloading
Merge pull request #3449 from retronym/topic/opt11

Another grab bag of compiler optimizations
Add repl as dependency of test-junit Eclipse project.

Since 8f20fa23dbb5b000f0889132b8c6e2acfff096b3 junit tests depend on
repl. We need to reflect that dependency in our Eclipse project files.
Merge pull request #3473 from gkossakowski/update-eclipse-files

Add repl as dependency of test-junit Eclipse project.
Merge pull request #3469 from adriaanm/t8239

 don't loop forever in ContextTrees.locateContextTree
Merge pull request #3395 from adriaanm/dist-cleanup

Dist cleanup
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!