SI-7269 Rework MapLike#retains to account for desugaring change

`MapLike#retains` contains a for-comprehension that relied on the strict
`filter` by its generator. You can't, in general, iterate a mutable map
and remove items in the same pass.

Here's the history of the desugaring of:

    def retain[A, B](thiz: mutable.Map[A, B])(p: (A, B) => Boolean): thiz.type = {
      thiz.foreach {
        case (k, v) =>
          if (p(k, v)) thiz -= k
      }

Before regression (c82ecabad6~1):

    thiz.filter(((check$ifrefutable$1) => check$ifrefutable$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => true
       case _ => false
    })).withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

After regression (c82ecabad6, which incorrectly assumed in the parser that
no filter is required for isInstanceOf[Tuple2])

    thiz.withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
      case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

After the reversion of c82ecabad6, v2.10.2
This is also after 365bb2b4e, which uses `withFilter` rather than `filter`.

    thiz.withFilter(((check$q$1) => check$ifrefutable$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => true
       case _ => false
    })).withFilter(((x$1) => x$1: @scala.unchecked match {
       case scala.Tuple2((k @ _), (v @ _)) => p(k, v).unary_$bang
    })).foreach(((x$2) => x$2: @scala.unchecked match {
      case scala.Tuple2((k @ _), (v @ _)) => thiz.$minus$eq(k)
    }));

This commit does the same as `SetLike#retains`, and converts the map to
an immutable list before the rest of the operation.
SI-7818 Cast our way out of extended existential angst

`substituteSymbols` is not sophisticated enough to
operate on `TypeSkolem`-s which are based on one of the
"from" symbols.

The pertinant usage of `substituteSymbols` for this bug in
in `Extender`. Recapping on that transform:

    // orig
    class C[T](...) extends AnyVal { def foo[U] = <rhs> }

    // transform
    class C[T] extends AnyVal { ... }
    object C  { def foo$extension[T', U'] = <rhs'> }

Where `<rhs'>` has been subtituted with, among other things,
`[T, U] ~> [T', U']`.

In this case our expected type contains a new type parameter
(of the extension method), whereas the type of the RHS contains
an existential skolem still pinned to the corresponding class type
parameter.

    tree.tpe         = Observable1#7037[_$1#12344]
    <_$1#12344>.info =  <: T#7040
    pt               = Observable1#7037[T#15644]

The limitation of substution is lamented in the comments
of `adaptMismatchedSkolems`, which faces the harder version of
the issue where the skolems are in the expected type.

But, we're in the "easy" case with the skolems in the tree's type;
we can cast our way out of the problem.

See also f335e447 / ed915c54.
SI-7767 avoid rejecting Scaladoc comments in early initializers

review by @retronym
SI-7767 Test case for Scaladoc on early initializers
Merge pull request #1 from retronym/ticket/7767-test

Test case for SI-7767
Merge pull request #2866 from retronym/ticket/7269

SI-7269 Rework MapLike#retains to account for desugaring change
Merge pull request #2922 from huitseeker/issue/7767

SI-7767 avoid rejecting Scaladoc comments in early initializers
Merge pull request #2916 from retronym/ticket/7818

SI-7818 Cast our way out of extended existential angst