SI-8323 Erase constant types for better double-def checks

Historically, Constant Types in method signatures have not been
erased. Rather, this was done in the backend.

This state of affairs leads to wrong decisions when the erasure
phase makes decisions about whether a pair of methods will clash
in bytecode.

This commit changes `ErasureMap` to take the underlying type of a
constant type.

This change obviates the fix for SI-4753, dcc07bd9f.

I've added test to show that constants are still inlined.

I believe this will answer the question in the backend about why
existential types make it that far; they come from the underlying
of a constant type representing a class literal. I'll leave it to
@lrytz to verify that the code in question is now dead and to remove
it in his backend work.

This change should be binary compatible with 2.11.0. Even though we
changed erasure, the combination of erasure and bytecode generation
lead to the same results.

Review by @lrytz @gkossakowski

I ran this patch by @odersky last Friday. He said it looks correct
so long as we verify it doesn't affect behaviour of inlining. He
showed my some code in Dotty that actually followed the new approach.

However, when I look at dotty master, I see that `ConstantTypes`
are not erased: https://github.com/lampepfl/dotty/blob/master/src/dotty/tools/dotc/core/transform/Erasure.scala#L129.

So, clarification by @odersky, too.
Why does `t"Class[String]".deconst` evaluate to t"Class[_]"? What's the representation of `t"Class[String]"` here?