Dummies: add ContainingAnyKey to AnyDictionary for full containment parity

[Reefact]

Problem

AnyDictionary now exposes ContainingKey(TKey) (added in #286), the concrete-key analogue of AnyCollection.Containing(TItem). But AnyCollection also offers ContainingAny(IAny<TItem>) — contain a value drawn from a generator at generation time — and AnyDictionary has no key equivalent. The dictionary containment surface is therefore still one method short of the collection surface.

Direction

Add ContainingAnyKey(IAny<TKey>) mirroring AnyCollection.ContainingAny:

• route to the key state's CollectionState.WithContaining(IAny<TKey>, ...) (the generator overload already exists), so the drawn key takes one entry's room and the bounded dedup-draw / cardinality plumbing is inherited unchanged — exactly as ContainingKey inherits it;
• null-guard the generator (ArgumentNullException), like ContainingAny;
• label it ContainingAnyKey(<generator>) in the conflict messages;
• name it ContainingAnyKey (not a bare ContainingAny) for the same reason ContainingKey is not a bare Containing: a dictionary's elements are key/value pairs, so the surface should stay explicit about what it constrains.

Acceptance criteria

• Any.DictionaryOf(keys, values).ContainingAnyKey(g) produces a dictionary whose keys include one drawn from g, with the same behaviour as SetOf(...).ContainingAny(g).
• A null generator throws ArgumentNullException.
• The new member is declared in both per-TFM PublicAPI.Unshipped.txt baselines (netstandard2.0 and net8.0).
• Tests exercise it, including the draw landing outside the key generator's own domain.

Context

Follow-up to #225 / #286, which added ContainingKey(TKey) and deliberately left the generator-drawn variant out of scope. Small, mechanical addition: the CollectionState.WithContaining(IAny<T>, ...) machinery already exists and is what ContainingAny uses.