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
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
SI-6493 more robust symbol handling in existentialTransform

The fix is only enabled under -Xexperimental, because the
full fix is blocked by SI-2071.

To illustrate the problem, let's compute the result type for

```
def foo = { class Foo { class Bar { val b = 2 }}; val f = new Foo; new f.Bar }
```

Note the inconsistent symbol ids in:

rawSyms     = List(value f#49740, class Foo#49739, class Bar#49742)
quantifiers + their infos =
  type f.type#49774 <: AnyRef{type Bar#49762 <: AnyRef{val b#49764: Int}} with Singleton,
  type Foo#49775    <: AnyRef{type Bar#49770 <: AnyRef{val b#49772: Int}},
                              type Bar#49773 <: AnyRef{val b#49758: Int}

It makes sense to subst the symbols in tp, but the modifyInfo will have
little effect on quantifiers. Luckily, coevolveSym will fix up some of
the inconsistencies, so that we get `f.type#49774.Bar#49762`, which is
extrapolated to `AnyRef{type Bar#49868 <: AnyRef{val b: Int}}#Bar#49868`.

The intermediate type `f.type#49774.Bar#49762` motivates the need for
the `.substSym` above, as `.subst` does not touch the `Bar#49742` in
the `f#49740.Bar#49742` that we start out with.

The remaining problem is that ExistentialExtrapolation will not consider
type Bar#49868 as existentially bound. Instead, it's looking for the
stale version in quantifiers, Bar#49773. If it was looking for Bar#49868,
the result type would simply be `AnyRef{val b: Int}`

TODO: figure out how to compute the full set of quantifiers for extrapolation
      the `doSubst(tp)` will clone more symbols, so we'll probably need to
      traverse its result and somehow correlate the contained symbols to
      those in `quantifiers`...