reflection API compatibility with 2.10.x

This is just one of the possible strategies for compatibility with
reflection API of 2.10.x family. Here’s the discussion:

1) Do nothing.

Document the fact that we’ve organized internal APIs in a separate module
and let people figure out themselves.

Pros: no boilerplate on our side.
Cons: potential for confusion, major upfront migration effort.

2) (This commit). Introduce a compatibility pack with a manual import.
Compatibility pack lives in a separate module that has to be manually imported.
People will get compilation errors when trying to compile macros using
internal APIs against 2.11, but those will be quenched by a single
`import compat._` import. Compatibility stubs would still produce
deprecation warnings, but people can choose to ignore them to alleviate
migration costs.

Pros: brings attention of the users to the fact that they are using
internal APIs by providing a more powerful nudge than just deprecation.
Cons: even though migration effort is trivial, it is still non-zero.

3) Deprecate internal APIs in-place.

Pros: zero migration effort required.
Cons: those who ignore deprecations will be unaware about using internal APIs,
there will be some naming conflicts between Universe.xxxType and internal.xxxType
type factories.