minor typos in the doc of applyOrElse
Test case for SI-8372: issue with ArrayOps.unzip

This commit merely documents current (suboptimal) error message printed
for the code reported in SI-8372. The next commit will fix the problem.
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-8372: unspliceable type printed in error message

The b8a76f688c6ce2a4c305da064303bb46b53be875 introduced ArrayOps.{unzip,
unzip3} methods. Both of those methods have ClassTags as context bounds on
their type parameters so they can create (and return) instances of Arrays.
The type inference for those methods is supposed to be guided by
implicit evidence that T <: (T1, T2) (or T <: (T1, T2, T3) in unzip3 case).
However, context bounds are desugared into implicit parameters that
prepended in front of implicit parameters declared in source code. That
means the implicit evidence won't have a chance to guide type inference
because it comes as last implicit parameter.

This commit desugars context bounds and puts them at the end of implicit
parameter list. This way type inference is guided properly and we get
expected compiler errors for missing class tags.

The change to parameters order breaks binary compatibility with respect
to 2.11.0-RC1. I added filters to our binary compatibility configuration
files. We can get rid of them as soon as 2.11.0 is out.
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
SI-8369 resetAttrs now correctly accounts for skolems

resetAttrs (née resetLocalAttrs) has been oblivious to existence of skolems.
Not anymore, which prevents us from reverting to the untyper nightmare.
Merge pull request #3605 from gkossakowski/issue/SI-8372

SI-8372: unspliceable type printed in error message
Addresses pull request feedback
Merge pull request #3610 from xeno-by/ticket/8369

SI-8369 resetAttrs now correctly accounts for skolems
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 #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
Move extra tuple placeholder case to reifyTreePlaceholder