Fix MA0113 NullReferenceException and named-argument false negatives

[meziantou]

The crash

_ = new DateTime(1970, 1, 1, 0, 0, 0, null);

binds to DateTime(int, int, int, int, int, int, Calendar). The 7-argument branch of UseDateTimeUnixEpochAnalyzer passed that null Calendar argument to IsDateTimeKindUtc, which did:

return argument.Value.TryGetConstantValue(out var value, cancellationToken) && (DateTimeKind)value! == DateTimeKind.Utc;

A null literal has ConstantValue.HasValue == true with a null value, so unboxing it to the DateTimeKind struct threw a NullReferenceException. The ! suppressed the only compile-time signal that value was nullable.

An unhandled analyzer exception surfaces as AD0001 and disables MA0113 for the rest of the compilation; in the IDE it recurs while the user types. The trigger is ordinary, compiling C#.

IsDateTimeKindUtc now verifies the argument's parameter type is System.DateTimeKind before looking at the constant, and pattern-matches it (value is int intValue) instead of unboxing. Either check alone stops the crash; both are cheap.

The positional-argument assumption

The rule also indexed IObjectCreationOperation.Arguments positionally, assuming parameter order. Arguments is in source order, so this was a real false-negative source rather than a theoretical one — any named-argument reordering silently defeated the rule:

_ = new DateTime(day: 1, month: 1, year: 1970); // MA0113 was not reported

ArgumentsEquals now indexes the expected values by IParameterSymbol.Ordinal and requires every leading parameter to have been matched. The arguments the rule inspects on their own — the DateTimeKind, the TimeSpan offset, and the DateTime.UnixEpoch reference — are looked up by ordinal through a new GetArgument helper instead of Arguments[n].

As a side effect, trailing parameters the rule does not model (the Calendar of DateTimeOffset(..., Calendar, TimeSpan)) are now skipped by ordinal rather than compared against an int, so they can neither crash nor accidentally match.

Tests

8 cases added to UseDateTimeUnixEpochAnalyzerTests: the null and non-null Calendar overloads for both DateTime and DateTimeOffset, and named/reordered arguments in both the match and the non-match direction.

I ran the new tests against the unfixed analyzer first to confirm they are meaningful — 4 failed, including the AD0001 / NullReferenceException on new DateTime(1970, 1, 1, 0, 0, 0, null) and three missed diagnostics on reordered named arguments.

With the fix, all 32 tests in the class pass on Roslyn 4.8, 4.14, 5.0, 5.6 and 5.9, and the full 3884-test default-version suite passes. dotnet run --project src/DocumentationGenerator produced no markdown changes, as expected for a behavior-only fix.