.Count(itemAssertion) per-item overload loses specialised source

[thomhurst]

Related: #5703, #5704, #5705, #5706 (same pattern).

Problem

CollectionAssertionBase.Count(Func<IAssertionSource<TItem>, Assertion<TItem>?> itemAssertion, ...) passes a generic IAssertionSource<TItem> into the lambda. When TItem is a string, collection, dictionary, or set, specialised assertions on the item are unreachable.

Repro

// IEnumerable<string>
await Assert.That(items).Count(s => s.Contains(\"foo\")); // fails: string-specific Contains not on IAssertionSource<string>

// IEnumerable<List<int>>
await Assert.That(listOfLists).Count(l => l.HasCount(3)); // fails

Affected signature

TUnit.Assertions/Sources/CollectionAssertionBase.cs:167

public CollectionCountSource<TCollection, TItem> Count(
    Func<IAssertionSource<TItem>, Assertion<TItem>?> itemAssertion,
    ...)

Proposed fix

Add specialised Count overloads keyed on TItem shape (string / IEnumerable / IDictionary / ISet / ...), passing the matching specialised source into the lambda. Use OverloadResolutionPriority for compiler steering.

Acceptance

• Specialised assertions reachable inside the .Count(item => ...) lambda for string/collection/dict/set items.
• Tests cover each specialised element shape.

[thomhurst]

Follow-up: PR #5764 (issue #5706) introduced a cleaner pattern for the same family — IAssertionSourceFor<TItem, TSelf> with static abstract Create(item, label). The Count(itemAssertion) overloads in TUnit.Assertions/Extensions/AssertionExtensions.cs:1825-2077 use the same shape this PR refactored away.

Reference for refactoring the Count overloads:

• New interface: TUnit.Assertions/Core/IAssertionSourceFor.cs
• Generic dispatch entry: TUnit.Assertions/Conditions/ListAssertions.cs (Satisfies<TSource> method)
• Thin per-type delegators: TUnit.Assertions/Extensions/ListItemAtSatisfiesExtensions.cs

To apply here:

1. Add a generic Count<TSource>(Func<TSource, IAssertion?>, ...) instance method on CollectionAssertionBase constrained where TSource : IAssertionSourceFor<TItem, TSource>, mirroring the new Satisfies<TSource>.
2. Convert interface-shape Count overloads (IEnumerable, IList, IReadOnlyList, IDictionary, IReadOnlyDictionary, ISet, IReadOnlySet, T[]) into one-line delegators that call source.Count<XxxAssertion<T>>(itemAssertion, expression).
3. Concrete-type overloads (List<T>, HashSet<T>, Dictionary<K,V>) cannot use the generic path — ListAssertion implements IAssertionSourceFor<IList<T>, ...> not <List<T>, ...> (variance limitation). Keep them calling the existing CountSpecialised private helper.
4. Wrap the new generic entry + interface-shape delegators in #if !NETSTANDARD2_0. netstandard2.0 retains existing specialised behaviour through the CountSpecialised path.

Estimated saving: ~150 LOC out of the current ~250 LOC for the Count overload block.