Unify "object Foo" and "Foo.type".

The source of many bugs over the years is that the first is
represented as a TypeRef and the second a SingleType.  Over a
great period of time I figured out how to shield us from the
more obvious bug manifestations, but a recent comment by adriaan
jarred me into realizing that we can fix it at the source.

This commit changes <:< and =:= to recognize when those two
representations are being compared and to treat them as equivalent
regardless of which is on the left.  The reason I don't quash one
representation entirely is that a fair bit of code depends on
singleton types having an underlying type which is not the same,
and regardless of that it would entail more changes and more risk.

The change allows removing the type inference conditions which
worried about this, and also fixes SI-4910.

scala> val t1 = typeRef(ScalaPackageClass.thisType, NoneModule.moduleClass, Nil)
t1: $r.intp.global.Type = None.type

scala> val t2 = t1.narrow
t2: $r.intp.global.Type = None.type

scala> (t1.getClass, t2.getClass)
res20: (Class[?0], Class[?0]) forSome { type ?0 <: $r.intp.global.Type; type ?0 <: $r.intp.global.Type } =
  (class scala.reflect.internal.Types$ModuleTypeRef,class scala.reflect.internal.Types$UniqueSingleType)

scala> ((t1 =:= t2, t2 =:= t1, t1 <:< t2, t2 <:< t1))
res21: (Boolean, Boolean, Boolean, Boolean) = (true,true,true,true)

1 files changed, 6 insertions, 0 deletions

diff --git a/test/files/pos/t4910.scala b/test/files/pos/t4910.scala
new file mode 100644
index 0000000000..c66fd523f5
--- /dev/null
+++ b/test/files/pos/t4910.scala
@@ -0,0 +1,6 @@
+class A {
+  implicit object foo
+  // it compiles if we uncomment this
+  // implicit val bar = foo
+  implicitly[foo.type]
+}