Fix MA0183 false positive and missed diagnostic when named arguments are reordered

[meziantou]

What changed

StringFormatShouldBeConstantAnalyzer (MA0183) located the format string by indexing IInvocationOperation.Arguments positionally. That collection is in evaluation/source order, so when named arguments are written out of parameter order the analyzer picked the wrong operand:

_ = string.Format(arg0: "hello", format: "{0}");   // false positive: "hello" treated as the format string
_ = string.Format(arg0: x, provider: c, format: "abc"); // missed diagnostic

The same applied to StringBuilder.AppendFormat and Console.Write/Console.WriteLine.

The analyzer now works with parameter ordinals instead of argument positions:

• GetFormatArgIndex(operation, …) became GetFormatParameterOrdinal(method, …): the IFormatProvider overload is detected from IMethodSymbol.Parameters, which is always in declaration order, and the method returns a parameter ordinal rather than an argument index.
• A new GetArgumentForParameter helper resolves the format argument by matching IArgumentOperation.Parameter.Ordinal, replacing operation.Arguments[formatArgumentIndex] and its bounds check.
• HasFormattingArguments iterates every argument and keeps the ones whose Parameter.Ordinal is greater than the format parameter's ordinal, instead of slicing the array from formatArgumentIndex + 1.

Tests

7 cases added to StringFormatShouldBeConstantAnalyzerTests, covering reordered named arguments for string.Format (with and without provider:), StringBuilder.AppendFormat and Console.WriteLine, in both the false-positive and the missed-diagnostic direction. 4 of them failed before the fix (3 false positives, 1 missed diagnostic).

Verification

• StringFormatShouldBeConstantAnalyzerTests: 62 tests, green on roslyn4.8, roslyn4.14, roslyn5.0, roslyn5.6 and roslyn5.9.
• Full suite on the default version (roslyn5.9): 3916/3916 passing.
• dotnet run --project src/DocumentationGenerator exits 0 with no markdown changes — this is a behavior fix that does not alter the documented rule.

Note for the reviewer

The report that prompted this also flagged the same positional assumption in UseDateTimeUnixEpochAnalyzer.ArgumentsEquals. That no longer applies: it already matches on argument.Parameter.Ordinal and its doc comment states it is order-independent, so it is left untouched here.