SI-8955 Fix hanging fork-join pool via parallel collections

A recent change [1] to Scala's default fork join thread pool caused
intermittent deadlocks. This is only visible in the development series
of Scala, 2.12.0-SNAPSHOT.

We changed our thread factory to place a hard limit the number of
threads created (equal to the desired parallelism.)

I have extracted a test case [2] that uses jsr166e directly, rather
than using Scala's parallel collections and abstractions on top of FJ.

In the comments of the bug, Viktor suggests this was too aggressive
and instead we ought to increase the limit to parallelism + 256
(with a system property override.)

He explained:

> The number 256 is going to be the default for the max threads for
> FJP in Java9 (down from 32k) so this change will harmonize the
> settings while making it possible to override from the outside.
>
> The cause of the deadlock is twofold:
>
> 1) The test uses ExecutionContext.global, which is not designed
>    for typical ForkJoin workloads since it has async = true
>    (FIFO instead of LIFO)
> 2) And we capped the default max number of threads to be created
>    when doing managed blocking from 32k to number of cores
>    (a tad too aggressive it seems)

Through testing, I found that for this example I could trigger the
hang with:

    parallelismLevel | maxThreads
    -----------------------------
                   2 | <= 4
                   4 | <= 9
                   8 | <= 11
                  16 | <= 15

I have emailed concurrency-interest [3] to help analyse the problem
further, but in the interest of avoiding hangs in the
scalacheck/parallel-collections test, I'm implementing Viktor's
suggestion in the interim.

[1] https://github.com/scala/scala/pull/4042
[2] https://gist.github.com/retronym/2e14cdab6d5612562d95
[3] http://markmail.org/message/czphdyjxpkixeztv
Merge pull request #4090 from retronym/ticket/8955

SI-8955 Fix hanging fork-join pool via parallel collections
SI-8862 Fix treatment of inherited implicits in package objects

Two spots in implicit search fell prey to a trap with package
objects. Members of a package object are entered into the scope
of the enclosing package, but that doesn't form a suitable prefix
for determing the member type.

A REPL transcript paints a picture that speaks a 1000 words:

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

package p { class C[A] { def foo: A = ??? }; object `package` extends C[String] }

// Exiting paste mode, now interpreting.

scala> val p = rootMirror.getPackageIfDefined("p")
warning: there was one deprecation warning; re-run with -deprecation for details
p: $r.intp.global.Symbol = package p

scala> p.info.decls
res0: $r.intp.global.Scope = Scopes(class C, package object p, method foo)

scala> val foo = p.info.decl(TermName("foo"))
foo: $r.intp.global.Symbol = method foo

scala> p.typeOfThis memberType foo
res1: $r.intp.global.Type = => A

scala> val fooOwner = foo.owner
fooOwner: $r.intp.global.Symbol = class C

scala> p.info.decl(nme.PACKAGE).typeOfThis memberType foo
res3: $r.intp.global.Type = => String
```

This commit detects if we find an implicit in a package module,
and then uses the self type of the corresponding package object
as the prefix for the `ImplicitInfo`. This is done in both
`Context.implicitss` (which collects in-scope implicits), and
in `companionImplicitMap` (which harvests them from the implicit
scope.) In addition, it was necessary / possible to remove a special
case that excluded package object implicits, the referenced tests for
SI-3999 now pass without this.
More uniform treatment of package objects

  - Introduce `Symbol#packageObject` and `Type#packageObject`
    to lookup the member package object of a package class/module,
    and use this far and wide.
  - Replace the overly complicated (and still buggy) implementation
    of `Context#isInPackageObject` with a one liner. The simplifying
    insight is that if we select a symbol from a package prefix
    that does not own that symbol, it *must* have really been
    selected from the package object.
  - Change implicit search to use the cache in
    `ModuleSymbol#implicitMembers` via `Type#implicitMembers`,
    which lets the client code read more naturally.

Fixes a bug with `adapt::insertApply` that Adriaan spotted in a feat
of lateral thinking. This is tested in t8862b.scala. alladin763.scala
adds the test case from the bug originally remedied by `insertApply`
to check we haven't regressed.
SI-8575 Fix subtyping transitivity with aliases, compound types

Thanks to @b-studios and @Blaisorblade for investigation into this
bug.

`RefinedType#normalize` is responsible for flattening nested
compound types to a flat representation.

Types are normalized during `=:=` in search of a successful
result.

This means that `((A with B) with C) =:= (A with B with C)`.

However, if we introduce a type alias for `A with B` on the LHS,
the attempt at flattening is thwarted.

This commit changes normalization of refined types. If a parent is
an alias for another refined type, it is dealiased during the
flattening process.

Two tests are included. The first demonstrates a symptom of this
problem: failure to install a bridge method resulted in a linkage
error.

The second test uses the reflection API to directly show transitivity
of subtyping now holds.

Targetting at 2.12, as bug fixes in subtyping usually can be shown
to lead to binary incompatibilities between code using the old and
new compilers.
Merge pull request #3981 from retronym/ticket/8575-2

SI-8575 Fix subtyping transitivity with aliases, compound types
SI-7521 Fix erasure of parametric value classes.

`Erasure.boxingErasure` exists to ensure that we use boxed primitives
to represent the value, if the value class has type parameters
referred to by its element type.

However, this is implenented with a type map that runs deeply
across the type. In the enclosed test case, we have
`Repr=Array[Int]`, which should be erased to `Array[Int]`, _not_
to `Array[Integer]`.

This commit ensures that the `boxingErasure` map only applies
boxing at the top level, and not within array arguments. (Other
type arguments will be erased, so we don't have to deal with them.)
SI-8835 Lazier slice for Iterator

An iterator for slicing that does not drop eagerly.

A series of `take m drop n` that results in nothing taken
will not call the underlying iterator.

Chained invocations do not create intermediate iterators.

This PR against 2.12 (because of the change to laziness)
does not include the expanded unit test from #4075.

Fix the parallel iterable splitter, which overrides `take`
and `slice`, to also override `drop`. Drop is now eager
there, like the drop of slice.

Enhance `stringOf` to handle `ParIterable` again. A commit
from a previous decade added that under the aegis of `Iterable`.
As of 2.11, `stringOf((0 until 512).to[Vector].par, 10)`
does not truncate.
Merge pull request #4001 from retronym/ticket/8862

SI-8862 Fix treatment of inherited implicits in package objects
SI-8251 Remove ListBuffer.readOnly as deprecated

Complete the story arc.
Merge pull request #4086 from som-snytt/issue/8835-2.12.x

SI-8835 Lazier slice for Iterator
Merge pull request #4140 from som-snytt/issue/8251

SI-8251 Remove ListBuffer.readOnly as deprecated
Merge pull request #4124 from retronym/ticket/7521

SI-7521 Fix erasure of parametric value classes.