Type#contains should peer into RefinementTypeRef-s

Usually, `contains` should not look into class symbol infos.
For instance, we expect that:

```
scala> trait C { def foo: Int }; typeOf[C].contains(IntClass)
defined trait C
res1: Boolean = false
```

We do, however, look at the decls of a `RefinedType` in contains:

```
scala> typeOf[{ def foo: Int }].contains(IntClass)
res2: Boolean = true
```

Things get a little vague, however, when we consider a type ref
to the refinement class symbol of a refined type.

```
scala> TypeRef(NoPrefix, typeOf[{ def foo: Int }].typeSymbol, Nil)
res3: $r.intp.global.Type = AnyRef{def foo: Int}

scala> .contains(IntClass)
res4: Boolean = false
```

These show up in the first element of the base type seq of a refined
type, e.g:

```
scala> typeOf[{ def foo: Int }].typeSymbol.tpe_*
res5: $r.intp.global.Type = AnyRef{def foo: Int}

scala> typeOf[{ def foo: Int }].baseTypeSeq(0).getClass
res7: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef

scala> typeOf[{ def foo: Int }].typeSymbol.tpe_*.getClass
res6: Class[_ <: $r.intp.global.Type] = class scala.reflect.internal.Types$RefinementTypeRef
```

This commit takes the opinion that a `RefinementTypeRef` should be
transparent with respect to `contains`. This paves the way for fixing
the base type sequences of existential types over refinement types.
The implementation of `ContainsCollector` was already calling
`normalize`, which goes from `RefinementTypeRef` to `RefinedType`.
This commit maps over the result, which looks in the parents and
decls.

1 files changed, 9 insertions, 0 deletions

diff --git a/test/files/pos/typevar-in-prefix.scala b/test/files/pos/typevar-in-prefix.scala
new file mode 100644
index 0000000000..929648b789
--- /dev/null
+++ b/test/files/pos/typevar-in-prefix.scala
@@ -0,0 +1,9 @@
+trait Test1 {
+  abstract class Setting
+  def Bool: Setting
+
+  class C[T <: Setting](val s: T)
+  val setting1 = null.asInstanceOf[_1.s.type forSome { val _1: C[Setting] }]
+  // the derived accessor for this val was not using an inferred type, as was
+  // the intention of the implementation in MethodSynthesis.
+}