an important fixup for macro universe API

It seems that this.type doesn't cut it for stuff declared in a trait.
Downgrading this.type to Symbol and Type correspondingly in
SymbolContextApi and TreeContextApi.
SI-5756 correctly reifies local module classes

Unlike module classes that are going to be pickled (which are reified
as `<their module reification>.moduleClass), module classes of
local modules need to be reified as symbol defs.

Otherwise we get a stack overflow:
1) Local modules are deemed to be free terms,
2) All free symbols are reified together with their type signature (so that they
   can be a) inspected by anyone interested, b) compiled at runtime),
3) Reifying a type signature of a module involves reifying its module class,
4) Reifying a module class involves reifying a module and calling its module class,
<ad infinitum>

This stack overflow doesn't happen for locatable modules, because they don't need
to have their type signatures reified (these signatures can later be loaded from
pickles if it becomes necessary).
SI-6204 reifier no longer causes cyclic errors

When reifying certain trees/types reifier might decide that it needs to
introduce auxiliary symbols to represent non-locatable components of types

For example, when reifying a refined type we need to reify the symbols
that correspond to its members (aka RefinedType.decls). Since these symbols
are not stored in pickles, we can't do the usual staticClass(scala.Int) stuff,
and are forced to actually create corresponding symbols inside the reificode
(by "create" I mean literally create, by using newXXXSymbol methods).

It looks like a generally good idea to not only create those symbols naked,
but to also export their type signatures and annotations. However this brings
problems with type inference.

Say, a type of a method A depends on a type tag. To get a type of a type tag,
the compiler needs to expand the corresponding macro (when the macro is being
expanded, symbol A is marked as LOCKED). While reification macro expands,
it might want to reify certain symbol definitions (as explained above). If one
of these definitions is a class that contains method A, we're in trouble,
since reifying the corresponding ClassInfoType will eventually call A.info,
which will produce a cyclic reference error, because A is LOCKED.

An obvious solution is to check whether a reified symbol definition is locked.
If the symbol is locked, then the reifier bails (e.g. by reifying NoType
instead of the actual type signature of the symbol).

Being obvious this solution is also incorrect as illustrated by SI-6204.
Sure we can check whether a symbol itself is locked, but we cannot check
whether or not we reify someone who refers to the locked symbol.

As of such I'm telling the reifier to bail whenever it needs to reify a symbol
definition for a symbol that is not yet complete. Therefore reification
can no longer cause inference of method result types, which eliminates the
underlying problem.

This is a harsh measure, but taking into account that we have an RC planned
within a week, stability trumps completeness.
accommodates reflection meeting feedback
Merge pull request #1094 from scalamacros/ticket/6204

fixes to existential-related reification problems