Improve MA0042 async overload matching coverage

[meziantou]

Why

MA0042 overload detection was missing several realistic call-shape scenarios (generic inference, extension-vs-instance matching, ref-kind nuances, and numeric conversion compatibility), which caused false negatives in async context diagnostics.

What changed

• Expanded overload matching in OverloadFinder to better support:
  • method-generic inference/constraint validation during comparison
  • ref/out strictness with in/by-value compatibility
  • extension/instance comparable parameter normalization
  • safer implicit numeric conversion compatibility (including System.Half -> float/double)
• Improved async-equivalent candidate discovery in DoNotUseBlockingCallInAsyncContextAnalyzer by broadening lookup around receiver/type context.
• Added a large async-context test matrix covering:
  • generic compatibility (positive and negative)
  • numeric widening/narrowing and floating-point precision-sensitive cases
  • instance vs extension method matching
  • argument forms (default, null, named args) and modifier edge cases
• Updated DocumentationGenerator to use FindRequiredGitRepositoryRoot() and bumped Meziantou.Framework.FullPath to 1.1.18.

Validation

• dotnet test --filter "FullyQualifiedName~DoNotUseBlockingCallInAsyncContextAnalyzer_AsyncContextTests.Argument_ImplicitNumeric" (passed)
• dotnet test --filter "FullyQualifiedName~DoNotUseBlockingCallInAsyncContextAnalyzer_AsyncContextTests" (passed)
• dotnet run --project src/DocumentationGenerator currently fails in this worktree with Cannot find the current git folder in this environment; code was updated toward required FullPath usage.

[Griboedoff]

may be there should be separate analyzer without fix for in, ref and out, because modifiers are forbidden for async methods but you can rewrite it to async version

[meziantou]

The code should only accept the in modifier. out and ref would be incompatible. While it's an invalid modifier when you define an async method, an async method can use a method with a in parameter.

As the use-case is to replace method invocation, I think this is ok.

Task Foo(in int a) => throw null!;

async Task Bar(int a)
{
    await Foo(a); // Valid
}

[Griboedoff]

this sounds reasonable

But I'm talking about other case

bool TryA(int b, out Foo f) => throw null!;
Task(bool, Foo)> TryAAsync(int b) => throw null!;

I understand that it's a long shot for analyzer to guess this type of overload, but it can be usefull :)

[meziantou]

It would have more impact that just finding the overload. The code fix must be aware of it, not just using another method name, but assigning variables (it can be tricky depending on the context).