Add missing canonical combinators:
  - `def transform[S](f: Try[T] => Try[S])(implicit executor: ExecutionContext): Future[S]`
  - `def transformWith[S](f: Try[T] => Future[S])(implicit executor: ExecutionContext): Future[S]`
  - `def flatten[S](implicit ev: T <:< Future[S]): Future[S]`
  - `def zipWith[U, R](that: Future[U])(f: (T, U) => R)(implicit executor: ExecutionContext): Future[R]`

Add missing utilities:
  -  `val unit: Future[Unit]` in `object Future`
  -  `object never extends Future[Nothing]` in `object Future`
  -  `def defaultBlockContext: BlockContext` in `object BlockContext`
  -  `def toString: String` on stdlib implementations of `Future`

Refactors:
  - the `scala.concurrent.Future` trait to not explicit create any `Promises`,
    so that implementations can control implementation type,
    this is mainly facilitated through adding of the `transform` and `transformWith` methods.
  - the implementation of `ExecutionContextImpl` has been cleaned up
  - the `scala.concurrent.impl.DefaultPromise` has been reimplemented to not use `sun.misc.Unsafe`

Securing:
  - Add a self-check in `completeWith` and `tryCompleteWith` to avoid cycles in trait Promise
  - Capping the maximum number of threads for the global `ExecutionContext` to the max parallelism
  - Implementing (almost) all `Future` combinators on `transformWith` and `transform` means
     that `DefaultPromise` linking works on both `(flat)map` and `recover(With)`
  - Nested `blocking {}` should not spawn extra threads beyond the first.

Removes:
  - the private `internalExecutor` method in favor of an import in trait `Future`
  - the private `internalExecutor` method in favor of an import in trait `Promise`
  - the `AtomicReferenceFieldUpdater` in `AbstractPromise` since we're using `Unsafe`
  - `scala.concurrent.impl.Future` is no longer needed

Deprecates:
  - `Future.onSuccess` - discourage the use of callbacks
                         (and is also redundant considering `foreach` and `onComplete`)
  - `Future.onFailure` - discourage the use of callbacks
                       (and is also redundant considering `onComplete` and `failed.foreach`)
  - `ExecutionContext.prepare` - it was ill specced and it is too easy to forget to call it
                     (or even know when to call it or call it more times than needed)
  - All classes in scala.concurrent.forkjoin. Scala 2.12 will be Java 8+ and as such the jsr166e
    should be used as included in java.util.concurrent.

Reimplements:
  - `failed` - in terms of `transform`
  - `map` - in terms of `transform`
  - `flatMap` - in terms of `transformWith`
  - `recover` - in terms of `transform`
  - `recoverWith` - in terms of `transformWith`
  - `zip` - in terms of `flatMap` + `map`
  - `fallbackTo` - in terms of `recoverWith` + `recoverWith`
  - `andThen` - in terms of `transform`

Miscellaneous:
  - Giving the threads of `ExecutionContext.global` sensible names
  - Optimizes `object Future.successful` and `object Future.failed` are now separate implementations,
    to optimize for the result, avoiding doing work for the "other branch".
  - Optimizes `compressedRoot()` by avoiding double-calls to volatile get.

Documentation:
  - Almost all methods on `Future` and `Promise` have been revisited and had their ScalaDoc updated

Tests:
  - Yes
SI-8849 Makes `ExecutionContext.Implicits.global` ambiguous

There was an unfortunate side-effect from having `Implicits.global` be
of type `ExecutionContextExecutor`; it is more specific than `ExecutionContext`,
as such it would be picked over other `ExecutionContexts` in the implicit scope.
Merge pull request #4042 from viktorklang/wip-sip14-updates-√

SIP-14 improvements
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-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.