fixes compat for tree and type extractors

When I removed XXXDef(...) and XXXType(...) methods from the public API,
I put compatibility stubs in compat via implicit classes enriching
XXXExtractor traits with apply methods.

Unfortunately, this doesn't work, because if XXXDef or XXXType have
any kind of an apply method left in the public API, then implicit classes
won't even be considered when resolving calls to XXXDef(...) or XXXType(...).

Therefore I had to put those removed methods back and adorn them with an
implicit parameter that can only be resolved when "import compat._"
is in place. Quite extravagant, yes, but goes along the lines with the
design goals of the refactoring, which are:

1) Break source compatibility for users who are using methods that are
now moved to internal in order to attract attention.
2) Provide an easy way to fix the breakage by importing compat._, which
will pimp back all the missing APIs with deprecation warnings that are
going to guide migration.
some extension methods that I forgot to expose

Thanks, sbt. Once I'm done with sbt, I'll write up tests that ensure that
I haven't forgotten anything.
updates deprecation hints in compat

Now when we have internal.decorators, it is reasonable to advertise them
to the users.