Fix #8617: Check that there is no inheritance/definition shadowing

[odersky]

This implements the additional rule for name resolution:

It is an error if an identifier x is available as an inherited member
in an inner scope and the same name x is defined in an outer scope, unless

• the inherited member (has an overloaded alternative that) coincides with
  (an overloaded alternative of) the definition x
• x is global, i.e. a member of a package.

[odersky]

An example of the first exception is this:

class C(x: T):
  class D extends C(2):
    println(x)

Here x is defined and inherited, but that's not an error since it's the same x.

[odersky]

This was actually less cumbersome than I anticipated. Only a handful of places had to be updated, and the updates were straightforward (just insert a this.). That's now also automated with a -rewrite rule.

So in the end we produce errors for 3.0 and migration warnings under -laguage:Scala2Compat.

[odersky]

@biboudis Unfortunately we got out of sync with this on scalatest now. There were two branches that are now in conflict. Can you please rebase and make sure it passes?

[lrytz]

there is a backport of this to 2.13 in progress by @som-snytt. I'm testing it on a large codebase, and it would be helpful to skip the warning when the two symbols are aliases. Here are two minimized real-world examples that don't compile with Scala 3.2.1:

trait Context
class A[C <: Context](val c: C)
class B(val c: Context) { b =>
  val a = new A[c.type](c) {
    def m = c  // ambiguous, `this.c` vs `B.this.c`
  }
}

class C[T] { type TT = T }
object O {
  type TT = String
  class D extends C[TT] {
    def n(x: TT) = x  // ambiguous, `this.TT` vs `O.TT`
  }
}

Proposal to fix that: #16401