Consider binding historical new abstract methods as virtual

[Mono.Android.dll API Compatibility](https://github.com/dotnet/android/blob/main/Documentation/workflow/mono-android-api-compatibility.md) states that new abstract methods or non-default interface methods added to an existing type are bound to a C# implementation that throws `AbstractMethodError`, starting from `$(TargetFrameworkVersion)` v10.0.

As mentioned in [History](https://github.com/dotnet/android/blob/main/Documentation/workflow/mono-android-api-compatibility.md#history), in the past when new abstract methods were introduced, they were instead bound to abstract C# methods. This was a source breaking change, and binary compat was preserved by a linker step that injected implemented implementations of the abstract methods.

The proposal is to go back and apply the new policy to all historically introduced new abstract methods and non-default interface methods (on types that existed in some previous version). These should instead be bound as virtual, falling back to a throwing implementation. I believe this is supported by the generator via [`compatVirtualMethod`](https://github.com/dotnet/java-interop/pull/1088). This would allow us to remove FixAbstractMethodsStep in .NET 10.

Some more context: this came up in https://github.com/dotnet/runtime/issues/103987#issuecomment-2317759432 where we discussed the idea of keeping such methods abstract in the ref assembly, and virtual in the implementation, to preserve the compiler errors. But at the time I didn't realize there were already plans to bind them to virtual methods in 10.0+ - so it looks we're ok with binding new Java abstract methods in a way that's not a source-breaking change in .NET.

@jonathanpeppers @vitek-karas @jtschuster @agocke