some renamings

It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
  * typeSignature => info
  * declarations => decls
  * nme/tpnme => termNames/typeNames
  * paramss => paramLists
  * allOverriddenSymbols => overrides

Some explanation is in order so that I don’t get crucified :)

1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.

2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.

3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.

4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
addresses pull request feedback
moves Symbol.pos to public API

Seems to be useful to people, so why not expose it more widely?
SI-7044 deprecates Symbol.associatedFile

Before this commit, Symbol.associatedFile used to be broken in two ways.
Firstly, it was never autoloaded (just like we used to have flags,
privateWithin and annotations). Secondly, it was never filled in by runtime
reflection.

My first attempt at fixing those problems was, well, just fixing them.
However, its runtime implementation was based on a hacky function that
we were not very much excited about supported (see comments),
whereas its compile-time usefulness was somewhat questionable.

Therefore the second attempt at fixing this bug is deprecating the API
altogether, replacing it with `Symbol.pos.source`.

Since `Symbol.pos` isn't retained for runtime consumption,
`Symbol.pos.source` is still going to return `NoAbstractFile` as before
this commit, but that's left for future work, and suggested approach
is documented in SI-8259.
renames some methods in ReificationSupport

As per Denys's request, renames methods in ReificationSupport that are
eponymous to methods in Universe, so that we don't get nasty name
intersections.

This change is not source/binary-compatible, because we don't make any
promises about the contents of the build API. Feedback welcome.
addresses pull request feedback
Type.companionType => Type.companion

I think that the "type" suffix here is redundant, so let's rename this API
to reduce the annoyance potential.
addresses pull request feedback
provides extension methods for internal

Based on my scala/async migration experiences, I can say that having
to write `setType(tree, tpe)` instead of `tree.setType(tpe)` is a major
pain. That's why I think it makes sense to expose some functions in internal
as extension methods.
staticXXX now throw ScalaReflectionException

Previously this was scala.reflect.internal.MissingRequirementError,
but that's not good enough for the public API.
introduces Flag.STABLE

Used in async when lifting definitions used in multiple states of the
async state machine. These definitions need to be lifted to class members
of the state machine.
exposes additional TreeGen methods

Agains, this is something that's needed for async.
upgrades typingTransform

typingTransform and typingTransform's atOwner now work both with
solitary trees and Tree+Symbol couples.
makes internal.decorators signatures work

After fighting with path-dependent types to express wrappee.type,
I decided to take a different approach and replaced wrappee.type with
parametric polymorphism.
better appliedType signatures

Our users deserve better than this mouthful:
`appliedType(sym.asType.toTypeConstructor, List(targ1, ...))`
exposes Symbol.setOwner

Used by async.
SI-6785 exposes Symbol.flags, setFlag and resetFlag

My first feeling was not to expose Symbol.flags, because that would
inevitably lead to exposing more methods on FlagSet. However we do need
flag manipulation in async, which is representative of advanced macros,
so I'm caving in.
exposes scope mutation APIs

Also needed for async.