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
SI-8385 make sure $quasiquote$tuple gets reified properly

Previously due to greediness of SyntacticApplied there was a chance that
quasiquote tuple placeholder got reified as its representation rather
than its meaning.
Update quasiquote debug output minimization pass
SI-8331 make sure type select & applied type doesn't match terms

Due to tree re-use it used to be the fact that type quasiquotes could
match term trees. This commit makes sure selections and applied type and
type applied are all non-overlapping between q and tq.
Address pull request feedback

1. Tighten up the if else to avoid duplication
2. Add doc comments
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
Move extra tuple placeholder case to reifyTreePlaceholder
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