Implement full IL .overrides and virtual semantics

[kg]

The way .overrides and virtual work in IL, you can actually have multiple chains of virtual methods with the same name on an object, by using 'new' to establish a new chain. It's also possible to use .overrides to override ordinary virtual methods instead of just interface methods.

C# and VB.net don't use either of these features extensively (though it's possible to do the chains using a mixture of 'new' and 'virtual') but it is probably necessary to implement this at some point anyway.

[iskiselev]

Probably it's time to discuss ways for implementing this.

[iskiselev]

As I understand, this is covered by FailingTests\InheritedAndNewMethod.cs and FailingTests\VirtualAndNewMethods.cs. FailingTests\BaseFields.cs is also related to same problem.

[kg]

I don't understand this aspect of the CLR especially well, I should probably find time to read over the relevant parts of the spec and figure out how we'd make this work.

[iskiselev]

Probably when we will implement it, we should also think about members with compilercontrolled visibility.
Such members could have same name and signature. ILDASM works with tham by adding '$PST' + some unique identifier, and ilasm strip his identifier. Have not yet tested what JSIL will do with them (icsharpcode/ILSpy#186 - looks like they are supported by ILSpy), but even if we call them correctly due to '$PST' suffix, we still need handle this as special case in reflection.

[iskiselev]

We may use VirtualMethod (same as we use InterfaceMethod now) to select which class virtual method should be selected. The main problem with this aproach - class could have static method with same name as virual instance method, so we can't just attach VirtualMethods to class public interface (as we do with InterfaceMethods). We still could add $VitualMethods property to class public interface and attach it to them.

[iskiselev]

Really, we actually may need always use class-aware method specification, otherwise we we'll be unable select correct method in cases like #623.

[iskiselev]

Really, this and 623 are totally same problem - we can have same-named method that associated with different type in inheritance hierarchy, so we need specify in call which type method would we like to call.
So, same as with interface member, we should pass to signature as first aument pair of type and name.