[ApiCompat] Not catching removal of abstract keyword

[carlossanlop]

As reported in maintenance-packages dotnet/maintenance-packages#194 (and fixed in dotnet/maintenance-packages#202), ApiCompat did not react when the abstract keyword was removed from the DispatchProxy.Invoke method, but it should've caught it.

[dotnet-policy-service]

@dotnet/area-infrastructure-libraries a new issue has been filed in the ApiCompat area, please triage

[ericstj]

Here's the rule in old API Compat
https://github.com/dotnet/arcade/blob/bf4bcc14dc4b9884d684fbd92c2e044defd0d53e/src/Microsoft.DotNet.ApiCompat/src/Rules/Compat/CannotMakeNonVirtual.cs#L42-L55

It's only checking "IsVirtual". Which calls this ->
https://github.com/dotnet/arcade/blob/cb9979d0e7061c2252f4a3057c20eb72f503cff7/src/Microsoft.Cci.Extensions/Extensions/CSharp/CSharpCciExtensions.cs#L322
Which calls this in CCI ->
https://github.com/microsoft/cci/blob/659f31f9736a1e8ded870ee2132d91f87505148e/PEReaderAndWriter/PEReader/BinaryObjectModel.cs#L2196C1-L2198C1

So it's solely based on the method flag.

In the Roslyn ISymbol model they define virtual differently.
https://github.com/dotnet/roslyn/blob/3f2e5e2ba7145ae675e008e82069168c0496cc66/src/Compilers/CSharp/Portable/Symbols/Metadata/PE/PEMethodSymbol.cs#L577-L578

So it more closely maps to the actual language keyword.

So we'll need to check for abstract as well. We should review all the usage of IsVirtual throughout APICompat codebase to see if any other instances might exist where it wanted the broader meaning.