We disallow overriding of val parameters, which fixes the soundness problem
discovered in scala#16092.

There is one exception: If a val parameter is overridden by another val
parameter that can be shown to always have the same value (in the sense
established by Paramforwarding.inheritedAccessor). This exception is needed
to make a not-so-uncommon pattern of case class inheritance go through.

Example:

    abstract class A(val x: Int)
    case class B(override val x: Int) extends A(x)
    case class C(override val x: Int) extends A(x)
    case object D extends A(0)

Here, the `override val`s are necessary since case class parameters are always vals,
so they do override the val in class A. It should be noted that the override val generates
a second field, so this not a very efficient representation. A better design would be
to use an abstract field in `A`:

    abstract class A { val x: Int }
    case class B(val x: Int) extends A
    case class C(val x: Int) extends A
    case object D extends A { val a = 0 }

But that causes slightly more work for cases as in D. Which seems to be why the first pattern
is sometimes used. It might be desirable to disallow the second pattern, but that would cause
quite a bit of migration hassle since it requires synchronized changes at several places of
a class hierarchy.

Currently, the following CB projects have illegal overrides of val parameters

 - spire
 - scalaz
 - specs2
 - akka

I checked the spire issue and its seems to require a non-trivial refactoring to avoid the problem.
More than I could achieve, given that I know nothing of spire.

In light of this I think we can enforce the restriction only under -source future and make it a
deprecation warning for now.

Temporarily, always report an error instead of a deprecation warning to verify
that projects compile. This will be reverted in the next commit.