[c#] not requiring exact match for extension methods

[xavierpinho]

In #5245, we resolved an extension method only if there was exactly one potential match, which deviates from the referenced source documentation, which states the resolution should target the first match found. However, it's not clear the order in which matches should be considered -- or, at least, I couldn't find it. Based on experimentation, it seems to prioritise the compile-time type, as can be seen in the tests involving MyConcrete and MyAbstract. To this end, I relaxed tryResolveExtensionMethodInvocation to always pick the 1st match.

In doing so, also uncovered a bug in which two methods can share the same methodFullName. We should disambiguate e.g. DoStuff(List<string>) from DoStuff<T>(List<T>). Included an ignored test, since it's not handled here. Once these are disambiguated, we can potentially start sorting the potential matches, based on their type signatures.

AST-wise, given how extension methods are static methods and we were already encoding x.Foo() as Foo(x), it seems like no further changes are required.