SI-8013 Nowarn on macro str interpolation

When warning about stray "foo $bar" under `-Xlint`,
which may be missing an interpolator id, suppress
the warning if we're in the middle of a macro
expansion, since we have no useful heuristic to
apply to the expanded tree.

The test for whether the string is part of an
expanded tree is to check all open macros for
an expanded tree that contains the literal tree
under scrutiny. (This is deemed more paranoid
than looking for a macro application that is an
enclosing position.)
add method dequeueOption to immutable.Queue

This allows immutable.Queue to be used conveniently in functional code.
Method is in the spirit of `headOption` on seqs or `get` on maps. Also
adds a unit test for immutable.Queue.
SI-4841 Plugins get a class path

Let -Xplugin specify a class path (or multiple of them).

Each entry can be a jar or dir, and the first entry to supply
a plugin descriptor defines the plugin to load.

If no plugin is found on the path, then issue a warning if `-Xdev`.
This honors the legacy silent treatment (which scala-ide tests for).

In the proposed scheme, each plugin gets a class loader so that
plugins are isolated from each other.

Presumably, if compiler plugins were a rich ecosystem, in which
shared dependencies were required in incompatible versions, this
would have become a requirement by now.

(Updated with a `DirectTest` that uses two plugins, but keeping
the following as documentation.)

Partest can't do multiple plugins yet, but this is what it looks like:

```
skalac -Xplugin:sample.jar:useful.jar:util,needful.jar:another.jar:util,needful.jar:util:exploded -Xplugin-require:sample,another,other foo.scala

skalac -Xplugin:sample.jar:useful.jar:util,needful.jar:another.jar:util,needful.jar:util:exploded -Xplugin-require:sample,other -Xplugin-disable:another foo.scala

skalac -Xplugin:sample.jar:useful.jar:util,sample.jar:useful.jar:util -Xplugin-require:sample foo.scala
```
The manual test shows three plugins with various permutations of jars and dirs.

The manual test demonstrates that plugins only see classes on their class path:

```
Initializing test.plugins.SamplePlugin
needful.Needful? Failure(java.lang.ClassNotFoundException: needful.Needful)
useful.Useful? Success(class useful.Useful)
Initializing more.plugins.AnotherPlugin
needful.Needful? Success(class needful.Needful)
useful.Useful? Failure(java.lang.ClassNotFoundException: useful.Useful)
Initializing other.plugins.OtherPlugin
```

Disabling a plugin results in a message instead of silent suppression:

```
Disabling plugin another
```

The duplicate plugin class test must still be honored:

```
Ignoring duplicate plugin sample (test.plugins.SamplePlugin)
Initializing test.plugins.SamplePlugin
needful.Needful? Failure(java.lang.ClassNotFoundException: needful.Needful)
useful.Useful? Success(class useful.Useful)
```

If the path is bad, then missing classes will report which plugin induced
the error:

```
Error: class not found: util/Probe required by test.plugins.SamplePlugin
Error: class not found: util/Probe required by more.plugins.AnotherPlugin
Initializing other.plugins.OtherPlugin
needful.Needful? Success(class needful.Needful)
useful.Useful? Failure(java.lang.ClassNotFoundException: useful.Useful)
error: Missing required plugin: sample
error: Missing required plugin: another
two errors found
```
Merge pull request #3225 from som-snytt/issue/8013-interp-nowarn

SI-8013 Nowarn on macro str interpolation
Merge pull request #3226 from ziggystar/patch-1

add method dequeueOption to immutable.Queue
SI-8054 Fix regression in TypeRef rebind with val overriding object

Regressed in 80767383fd / SI-7928

The condition added in that commit are necessary after refchecks but
poisonous before.

This still seems rather fragile: I wonder if `eliminateModuleDefs`
in `RefChecks` ought to flag the module symbol as `ARTIFACT` after
creating the accessor, so as to signal that it shouldn't be bound
anymore?
streamlines refchecking undesired symbol properties

Unifies `checkDeprecated`, `checkMigration` and `checkCompileTimeOnly`
into a single centralized point of reference that is now consistently
called from `checkTypeRef`, `transformIdent` and `transformSelect`.
deprecates macro def return type inference

With the new focus on quasiquotes in macro implementations, we now have
to change the way how inference of macro def return types works.

Previously, if the return type of a macro def wasn’t specified, we looked into
the signature of its macro impl, took its return type (which could only
be c.Expr[T]) and then assigned T to be the return type of the macro def.

We also had a convenient special case which inferred Any in case when
the body of the macro impl wasn’t an expr. That avoided reporting spurious
errors if the macro impl had its body typed incorrectly (because in that
case we would report a def/impl signature mismatch anyway) and also provided
a convenience by letting macro impls end with `???`.

However now we also allow macro impls to return c.Tree, which means that
we are no longer able to do any meaningful type inference, because c.Tree
could correspond to tree of any type.

Unfortunately, when coupled with the type inference special case described
above, this means that the users who migrate from exprs to quasiquotes
are going to face an unpleasant surprise. If they haven’t provided
explicit return types for their macro defs, those types are going to be
silently inferred as `Any`!

This commit plugs this loophole by prohibiting type inference from
non-expr return types of macro impls (not counting Nothing). Moreover,
it also deprecates c.Expr[T] => T inference in order to avoid confusion
when switching between exprs and quasiquotes.
Merge pull request #3237 from xeno-by/topic/macrodef-returntype-inference

deprecates macro def return type inference
Merge pull request #3246 from xeno-by/topic/compile-time-only

streamlines refchecking undesired symbol properties
SI-8008 Make q”f(..$xs)” only match trees with Apply node

Previously it also matched other nodes but returned Nil as value of xs.
This behavior was added for sake of consistentcy with q”f[..$ts]”. On
the other hand q”f[..$Nil]” == q”f” but q”f(..$Nil)” == q”f()” not q”f”.
Due to this deconstruction/construction symmetry was broken.

On the other hand applications also have q"f(...$xss)" option which is
infact similar to q"f[..$ts]". Splicing Nil into it also results in q"f".
SI-8016 Ensure that q”..$xs” is equivalent to q”{..$xs}”
SI-8009 Ensure that Idents preserve isBackquoted property
SI-6842 Make splicing less sensitive to precise types of trees

Previously trees that represent parameters, case clauses and
type variables had strictly defined ValDef, TypeDef and CaseDef
types which caused problems in compositionality.

Now this checks are moved to runtime so it's possible to pass
a tree that is CaseDef but has Tree type.
SI-7979 Fix quasiquotes crash on mismatch between fields and constructor
Move Liftable into the Universe cake; add additional standard Liftables

Previously we believed that having Liftable outside of the Universe will
bring some advantages but it turned out this wasn’t worth it. Due to
infectious nature of path dependent types inside of the universe one
had to cast a lot. A nice example of what I’m talking about is a change
in trait ArbitraryTreesAndNames.

Additionally a number of standard Liftables is added for types that are
available through Predef and/or default scala._ import: Array, Vector,
List, Map, Set, Option, Either, TupleN.
Provide a way for unapply macro to obtain a list of subpattens

This commit introduces internal attachment that allows unapply macros to
be aware of their sub patterns and tweak their expansion depending
on that info.

At the moment this is not possible due to the way pattern macros are
expanded:

	case MacroPat(inner1, inner2) => ...

During type checking this will expand as

	MacroPat.unapply(<unapply-dummy>)

Meaning that macro can’t see inner1 and inner2 in it’s macroApplication.
To circumvent this we attach that info as an attachment to the dummy.
Refactor Holes and Reifiers slices of Quasiquotes cake

This commit performs a number of preliminary refactoring needed to
implement unliftable:

1. Replace previous inheritance-heavy implementation of Holes with
   similar but much simpler one. Holes are now split into two different
   categories: ApplyHole and UnapplyHole which correspondingly represent
   information about holes in construction and deconstruction quasiquotes.

2. Make Placeholders extract holes rather than their field values. This
   is required to be able to get additional mode-specific information
   from holes (e.g. only ApplyHoles have types).

3. Bring ApplyReifier & UnapplyReifier even closer to the future where
   there is just a single base Reifier with mode parameter.

Along the way a few bugs were fixed:

1. SI-7980 SI-7996 fail with nice error on bottom types splices

2. Use asSeenFrom instead of typeArguments in parseCardinality.
   This fixes a crash if T <:< Iterable[Tree] but does not itself
   have any type arguments.

3. Fix spurious error message on splicing of Lists through Liftable[List[T]]
Introduce support for Unliftable for Quasiquotes

Unliftable is a type class similar to existing Liftable that lets
users to extract custom data types out of trees with the help of
straightforward type ascription syntax:

  val q“foo.bar(${baz: Baz})” = ...

This will use Unliftable[Baz] to extract custom data type Baz out of
a tree nested inside of the another tree. A simpler example would be
extracting of constant values:

  val q”${x: Int} + ${y: Int}” = q”1 + 2”
SI-7789 make quasiquotes deconstruct UnApply trees