SI-8869 Prevent ill-kindedness in type lambdas

When type checking an type application, the arguments are allowed
to be of kinds other than *. This leniency is controlled by the
`ContextMode` bit `TypeConstructorAllowed`.

(More fine grained checking of matching arity a bounds of type
constructors is deferred until the refchecks phase to avoid
cycles during typechecking.)

However, this bit is propagated to child contexts, which means
that we fail to report this error in the lexical context marked
here:

    T[({type x = Option}#x)]
        `-------------'

This commit resets this bit to false in any child context
relates to a different tree from its parent.
SI-8870 Fix markup errors in the Types section of the spec

Bad: `T'_n`
Good: `T_n'`
SI-8217 allow abstract type members in objects

Previously, abstract type members were allowed in objects only when inherited,
but not when declared directly. This inconsistency was not intended. In dotty,
abstract type members are allowed in values and represent existentials; so upon
discussion, it was decided to fix things to conform to dotty and allow such type
members. Adriaan also asked to keep rejecting abstract type members in methods
even though they would conceivably make sense.

Discussions happened on #3407, scala/scala-dist#127.
This code is improved from #3442, keeps closer to the current logic, and passes tests.

Existing tests that have been converted to `pos` tests show that
this works, and a new test has been added to show that local
aliases (ie term-owned) without a RHS are still rejected.
Merge pull request #4022 from retronym/ticket/8870

SI-8870 Fix markup errors in the Types section of the spec
SI-8267 Avoid existentials after polymorphic overload resolution

... which can be introduced by `memberType` for methods
with parameter types dependent on class type parameters.

Here's an example of such a type:

```
scala> class Bippy { trait Foo[A] }
defined class Bippy

scala> final class RichBippy[C <: Bippy with Singleton](val c1: C) {
     |   def g[A](x: A)(ev: c1.Foo[A]): Int = 2
     | }
defined class RichBippy

scala> :power
** Power User mode enabled - BEEP WHIR GYVE **
** :phase has been set to 'typer'.          **
** scala.tools.nsc._ has been imported      **
** global._, definitions._ also imported    **
** Try  :help, :vals, power.<tab>           **

scala> val g = typeOf[RichBippy[_]].member(TermName("g"))
g: $r.intp.global.Symbol = method g

scala> val c = new Bippy
c: Bippy = Bippy@92e2c93

scala> val memberType = typeOf[RichBippy[c.type]].memberType(g)
memberType: $r.intp.global.Type = ([A](x: A)(ev: _7.c1.Foo[A])Int) forSome { val _7: RichBippy[c.type] }

```

In this example, if we were to typecheck the selection
`new RichBippy[c.type].g` that existential type would be short lived.

Consider this approximation of `Typer#typedInternal`:

```scala
val tree1: Tree = typed1(tree, mode, ptWild)
val result = adapt(tree1, mode, ptPlugins, tree)
```

Given that `tree1.tpe` is not an overloaded, adapt will find its
way to:

```
  case tp if mode.typingExprNotLhs && isExistentialType(tp) =>
    adapt(tree setType tp.dealias.skolemizeExistential(context.owner, tree), mode, pt, original)
```

Which would open the existential as per:

```
scala> memberType.skolemizeExistential
res2: $r.intp.global.Type = [A](x: A)(ev: _7.c1.Foo[A])Int
```

However, if do have overloaded alternatives, as in the test case,
we have to remember to call `adapt` again *after* we have picked
the winning alternative.

We actually don't have a centralised place where overload resolution
occurs, as the process differs depending on the context of the
selection. (Are there explicit type arguments? Inferred type
arguments? Do we need to use the expected type to pick a winner?)

This commit finds the existing places that call adapt after
overloade resolution and routes those calls through a marker
method. It then adds one more call to this in `inferPolyAlternatives`,
which fixes the bug.
Merge pull request #4021 from retronym/ticket/8869

SI-8869 Prevent ill-kindedness in type lambdas
Merge pull request #4024 from retronym/ticket/8217

SI-8217 allow abstract type members in objects
Merge pull request #3995 from retronym/ticket/8267

SI-8267 Avoid existentials after polymorphic overload resolution
SI-4788/SI-5948 Respect RetentionPolicy of Java annotations

Note that I removed the check to ignore @deprecated:
- @deprecated extends StaticAnnotation, so they aren't
  supposed to show up in the RuntimeInvisibleAnnotation
  attribute anyway, and the earlier check for "extends
  ClassfileAnnotationClass" makes this check superflous
  anyway.
- Otherwise, if @deprecated was extending
  ClassfileAnnotationClass it would seem inconsistent
  that we don't emit @deprecated, but would do so for
  @deprecatedOverriding, @deprecatedInheritance, etc.
  Anyway, due to ClassfileAnnotation not working in
  Scala, and the additional check which only allows
  Java-defined annotations, this is pretty pointless
  from every perspective.