Get: Distribute over unions so a key missing on some members yields undefined

[ardittirana]

Fixes #1205

What was wrong

For a union base type, Get accessed the key on each member, but a member that lacked the key resolved to unknown — and unknown absorbs the rest of the union. So:

Get<{a: number} | {b: string}, 'a'> // was `unknown`, expected `number | undefined`
Get<{data: {type: 'x'; v: number} | {type: 'y'}}, 'data.v'> // was `unknown`

Fix

PropertyOf now detects a union first and, when distributing over its members, treats a missing key as undefined for that member. A missing key on a non-union type still resolves to unknown (the existing, documented behaviour — preserved by an explicit MissingProperty parameter).

Tests

Added cases to test-d/get.ts for: key present on all members, key present on some members (→ number | string | undefined), a direct union base type, and the unchanged non-union unknown case. npm run test:tsd and xo pass; no existing assertions changed.

[som-sm]

A missing key on a non-union type still resolves to unknown (the existing, documented behaviour — preserved by an explicit MissingProperty parameter).

I think the existing behaviour here is incorrect, this should also be undefined. More so, if for unions it's going to be undefined. Let's make it consistently undefined for missing properties.

[ardittirana]

Makes sense — consistency wins here, and you're right that it's odd to special-case non-unions once unions resolve missing keys to undefined. I've updated it so a missing key resolves to undefined for both union and non-union base types, matching lodash/dot-prop runtime behaviour.

Changes:

• PropertyOf no longer distinguishes the two cases; the now-redundant MissingProperty parameter on SinglePropertyOf is removed.
• The doc note now reads "Returns undefined if Key is not a property of BaseType".
• Updated the out-of-bounds / missing-key tests (tuples, array index, Get<{a: number}, 'b'>, etc.) from unknown to undefined.

Full tsd suite passes and lint is clean. Let me know if you'd prefer any wording tweaks in the docs.