SI-1503 don't assume unsound type for ident/literal patterns

The fix only kicks in under -Xfuture. We also warn under -Xlint.

What type should a variable bound to the value matched by a pattern have?
To avoid CCEs, it should be a type that's implied by the matching
semantics of the pattern.

Usually, the type implied by a pattern matching a certain value
is the pattern's type, because pattern matching implies instance-of checks.

However, Stable Identifier and Literal patterns are matched using `==`,
which does not imply a type for the binder that binds the matched value.

The change in type checking due to this fix is that programs that used to crash with a CCE
(because we blindly cast to the type of the pattern, which a `==` check does not imply)
now get a weaker type instead (and no cast). They may still type check, or they may not.

To compensate for this fix, change `case x@Foo => x` to `case x: Foo.type => x`,
if it's important that `x` have type `Foo.type`.

See also:
- SI-4577: matching of singleton type patterns uses `eq`,
  not `==` (so that the types are not a lie).
- SI-5024: patmat strips unused bindings, but affects semantics
minor code cleanup in the macro engine
SI-8321 whitebox bundles are now recognized as such

whitebox.Context <: blackbox.Context, so in order to check for blackboxity
it's not enough to check whether the context used is <: blackbox.Context.
bundles now reject invalid context types

Vanilla macros only allow blackbox.Context, whitebox.Context and
PrefixType refinements thereof. Bundles should behave in the same way.
prohibits polymorphic bundles

It's not like they were inducing bugs, but I can't see how polymorphism
can be useful for macro bundles, hence imho it's better to reduce the
number of degrees of freedom of the system.
more helpful bundle error messages

At the moment, bundle selection mechanism is pretty picky. If a candidate
bundle's parameter isn't either blackbox.Context, whitebox.Context or
PrefixType refinement thereof, then it's not a bundle and the user
will get a generic error.

However we can be a bit more helpful and admit classes that are almost
like bundles (looksLikeMacroBundleType), have them fail isMacroBundleType,
and then emit a much prettier error message to the user that would tell them
that bundles must be monomorphic and their sole parameter should not just
be any subtype of blackbox.Context or whitebox.Context.
more tests for macro bundles

Given the recent glaring oversight in macro bundles, I have to have more
tests in order to make sure that things are going to work as they should.
more clean up in the macro engine

Now when SI-7507 is fixed in starr, we can actually remove a workaround
and make a 10 line reduction in the size of Resolvers.scala.
SI-7962 Scalac runner does not work within Emacs's terminal

  - Always set the env.emacs system property - scalac only cares
    about whether the system property has a non-empty value, not
    whether it is set or not. Fixes 7962
SI-8324 fix permutation in test filename
Merge pull request #3574 from greenrd/SI-7962

SI-7962 Scalac runner does not work within Emacs's terminal
Merge pull request #3571 from xeno-by/ticket/8321

SI-8321 bundles can't be whitebox
Merge pull request #3559 from adriaanm/t1503

SI-1503 don't assume unsound type for ident/literal patterns
Merge pull request #3577 from adriaanm/pr3573-fixup

SI-8324 fix permutation in test filename
Add ScalaDoc to Quasiquotes and Liftables parts of api
SI-8330: Mismatch in stack heights

The SI-8233 / 9506d52 missed one case when we need to DROP a null from
a stack: when unboxed Unit is an expected type. If we forgot to do that
in a context where two branches were involved we could end up with
unbalanced stack sizes.

Let's fix that omission and a test covering that specific case to the
original test for SI-8233.

Fixes SI-8330.
Address pull request feedback
Merge pull request #3580 from gkossakowski/issue/SI-8330

SI-8330: Mismatch in stack heights
SI-8251 deprecate `ListBuffer::readOnly`

This is the first step towards fixing the unexpected behavior of `ListBuffer`.

Many of `ListBuffer`'s operations are forwarded to the underlying `List`,
essentially leaking that abstraction to clients that call e.g., `toIterable`.
When the buffer changes, the `Iterable` obtained through `toIterable` will
reflect that change.

To avoid this exposure, call `toList` to obtain an immutable copy.

See also:
https://groups.google.com/d/msg/scala-internals/g_-gIWgB8Os/kWazrALbLKEJ
https://gist.github.com/paulp/9081797
SI-6455 under -Xfuture, don't rewrite .withFilter to .filter

This has been deprecated for two major releases now,
but `filter`'s still preferred over `withFilter` in the wild.