Fix #2051: allow override T with => T or ()T

[liufengyun]

Fix #2051: allow override T with => T or ()T.

I'm not sure if this is the right fix. Could you please advise @DarkDimius ?

[odersky]

What about the following test:

abstract class C { val x: Int }
class D extends C { def x = 1 }

We are good if that one still gives the error

          overriding value x in class C of type Int;
          method x of type => Int needs to be a stable, immutable value

[liufengyun]

The case above is rejected by some other check, we still have the same error as before. I just added it as a neg test.

[odersky]

OK, I think we are good then. @smarter since you are currently playing with override val's do you see a reason why we should not do this?

[smarter]

Not that I can think of but this change still seems weird to me, what is special about constructor parameters here?

[DarkDimius]

otherwise LGTM

[DarkDimius]

it would be nice to add several fields to the body of the class that are overriden in a subclass.

It would also be nice to include tests with trait vals and trait constructors.

[liufengyun]

Thanks @DarkDimius , I just added tests in the latest commit.

[liufengyun]

@smarter the reason is that x: T is already present in the parent class, in post-typer, we just create a forwarder override def x: T = super.x.