Add OnUnresolvedSubtype callback to detect unregistered subtypes (#112)

[manuc66]

Closes #112

Problem

The reporter of #112 wants to detect, while deserializing a polymorphic tree, every object whose Type discriminator is not registered — without throwing on the first mismatch. Today the only way is a "trap" fallback type: its constructor records each unknown Type into a static list, which is not thread-safe and requires cleanup after deserialization.

Fix

Adds OnUnresolvedSubtype to all four builders (JsonSubtypesConverterBuilder / JsonSubtypesWithPropertyConverterBuilder, in both JsonSubTypes and JsonSubTypes.Text.Json). The callback fires once per JSON element whose subtype cannot be resolved: unknown or missing discriminator value, or no matching property in property-presence mode.

The hook sits at the existing single failure point in both backends (resolvedType ?? GetFallbackSubType(...)), so nothing changes when no callback is registered. UnresolvedSubtypeInfo exposes the parent type, the discriminator name and value, a HasDiscriminator flag (to distinguish a missing discriminator from an unknown value, both otherwise read as null) and the fallback subtype that will be used (null when none is configured).

Tests

• JsonSubTypes.Text.Json.Tests: 139 pass on net8.0 and net10.0. Six new tests: no callback when the subtype resolves, unknown value, missing discriminator, no fallback configured, one callback per unresolved element in a nested tree, property-presence mode.
• JsonSubTypes.Tests (net46): compiles, but the NUnit suite cannot execute under Linux/VSTest, so I validated the same six scenarios through a net8.0 harness against the netstandard2.0 build (all pass).

Honest notes

• The callback runs on the deserializing thread. A converter shared across threads calls it from several threads, so the callback must be thread-safe; I did not add locking or weak-event machinery.
• JsonPath is available in the Newtonsoft backend but not in System.Text.Json (resolution works on a JsonDocument, which carries no path), so I omitted it from the info type.
• The callback cannot override the resolved type. That would be a separate custom-type-resolver feature; say so here if you actually need it.

Feedback welcome on the API shape (method name, and what UnresolvedSubtypeInfo exposes).