Validate objects inside items that are collections

[tgharold]

Motivation

The validator enumerated a collection that a property holds, but never an item that is itself a collection. A List<List<T>>, a List<HashSet<T>>, an object[] that holds a list, or a list of ImmutableList<T> passed validation even when an object inside was invalid. A probe of v2.0.0, v2.2.0 and v2.3.3 shows the same result in all three, so this is a long-standing silent pass. Some shapes were caught only by accident, through a public property of the inner collection (Array.SyncRoot, Dictionary.Values), with paths such as Value[0].SyncRoot[0].Name.

The fix enumerates items that are collections and reports each level's index: Value[0][0].Name. Paths are now the same for every collection type, which is why this is a breaking change for the few shapes that had an accidental path. By the rule in RELEASE-PROCESS.md it needs a major version, so I expect it to ship in 3.0.

Summary

• An item that is a collection is validated as an object first, so its own attributes and IValidatableObject.Validate still run, then its items are enumerated before its properties are walked. A collection of simple values is not enumerated. The root object is not enumerated either, and that is pinned by tests.
• IsLeafType now treats a sealed class or struct that is a collection as a leaf only when its items are leaves. Without it, List<ImmutableList<T>> and lists of sealed collections were skipped as lists of values.
• Edge cases decided and tested: a collection that contains itself ends, a shared inner collection is walked once, and null or bracketed member names are joined without being inspected. A struct item that equals its default value, such as an unset ImmutableArray<T> or ArraySegment<T>, is skipped, because enumerating it throws.
• CHANGELOG has one BREAKING entry for the changed member names, with one line per shape and the new path, and one for enumeration side effects (lazy sequences run, a collection that throws now throws, a never-ending one hangs). The README has a new Collections section and a note that a struct reached by two routes is reported twice.
• Known limits, with guard tests: a struct collection held in a property is still not enumerated, and skipped specs describe the fix for the next release. A struct reached by two routes is reported twice because boxed copies cannot be matched by reference.

Test plan

• dotnet test on net8.0 and net10.0: 503 passed, 14 skipped, 0 failed. The 14 skipped include the next-release specs.
• The new specs failed on the code before the fix, and the guards pass on v2.3.3 source.
• Differential run of about 65 models against v2.3.3: every changed result is a new detection or a new path, and no new silent pass.
• dotnet build -p:IncludeNetFramework=true builds net481 with no warnings.
• CI, including net481 on Windows.