minor typos in the doc of applyOrElse
SI-8364 fixes cxTree lookup for imports

This is reminiscent of the bug that I recently fixed in paradise:
https://github.com/scalamacros/paradise/commit/0dc4e35883d357b7cbcdfd83b5b4821c1dcc0bb1.

When doing something non-standard with contexts, we usually have to keep
in mind that new contexts are created not only for trees that demarcate
blocks of code, but also for imports.
SI-8375 saner binary incompat errors for macros

Inspired by Brian McKenna's RC1 migration experience, this commit improves
macro impl binding validation in order to provide more helpful diagnostic
for this quite frequent class of errors.
SI-8368 respect user-supplied -Dscala.usejavacp in unix runner
SI-8370 fixes an infinite loop in repl init

Under a weird coincidence of circumstances provided by `sbt console-quick`,
new XML parsing logic in compiler plugin initialization could lead to stack
overflow errors.

Here's the abridged sequence events that led to this unfortunate problem
(full description can be found on the JIRA issue page):

1) Initialization of the compiler underlying the REPL would kick off
plugin initialization.

2) PluginDescription.fromXML would call into DocumentBuilderFactory, i.e.
DocumentBuilderFactory.newInstance.newDocumentBuilder.parse(xml).

3) That thing would call into javax.xml.parsers.SecuritySupport.getResourceAsStream,
requesting META-INF/services/javax.xml.parsers.DocumentBuilderFactory.

4) That request would get serviced by TranslatingClassLoader provided
by the REPL to expose dynamically compiled code.

5) TranslatingClassLoader would call translatePath that would call into
IMain.symbolOfIdent trying to map the requested resource onto one of the
classes defined by the REPL (which don't exist yet, because REPL hasn't
yet finished initializing).

6) IMain.symbolOfIdent would request IMain.global, which is exactly the
instance of the compiler that underlies the REPL, and that's currently
being initialized.

7..inf) Repeat until a StackOverflowError.
SI-8367 revert SI-8192's change to primaryConstructor when isJavaDefined

this is some weird stuff
Addresses pull request feedback
Merge pull request #3584 from martijnhoekstra/patch-1

minor typos in the doc of applyOrElse
Merge pull request #3603 from xeno-by/ticket/8364

SI-8364 fixes cxTree lookup for imports
Merge pull request #3606 from xeno-by/ticket/8375

SI-8375 saner binary incompat errors for macros
SI-8377 - Clarify the asynchronous requirement of ExecutionContext
Merge pull request #3613 from viktorklang/patch-1

SI-8377 - Clarify the asynchronous requirement of ExecutionContext
Merge pull request #3608 from adriaanm/t8368

SI-8368 respect user-supplied -Dscala.usejavacp in unix runner
Merge pull request #3607 from xeno-by/ticket/8367

SI-8367 revert SI-8192's change to primaryConstructor when isJavaDefined
Merge pull request #3594 from densh/si/8331

SI-8331 make sure type select & applied type doesn't match terms
Merge pull request #3609 from xeno-by/ticket/8370

SI-8370 fixes an infinite loop in repl init
Merge pull request #3611 from densh/si/8385

SI-8385 make sure $quasiquote$tuple gets reified properly
SI-8366 make partial function and match trees disjoint

Previously one could match a partial function with match quasiquote:

    scala> val q"$scrutinee match { case ..$cases }" = q"{ case Foo => Bar
    }"
    scrutinee: universe.Tree = <empty>
    cases: List[universe.CaseDef] = List(case Foo => Bar)

This was quite annoying as it leaked encoding of partial functions as
Match trees with empty tree in place of scrutinee.

This commit make sure that matches and partial functions are disjoint
and don't match one another (while preserving original encoding under
the hood out of sight of the end user.)
Add more tests for partial functions