Incorrect type inference for a field that is not optional, but has type of a union with undefined

## Bug Report ### Actual behavior If there is a non-optional attribute in an object that has a type of `something | undefined`, the logic that is skipping `undefined` is not reflected in the type, but still works in runtime: ```ts import { deepmerge } from 'deepmerge-ts' const a: { foo: string } = { foo: 'bar' } const b: { foo: number | undefined } = { foo: undefined } const c: { foo: number | undefined } = deepmerge(a, b) console.dir(c) // { foo: 'bar' } ``` That results in a compile-time type diverging from a runtime type (in the example, it's `string` in runtime and `number | undefined` in compile-time) The issue is not there if the field is marked as optional: ```ts const a: { foo: string } = { foo: 'bar' } const b: { foo?: number | undefined } = { foo: undefined } const c: { foo: string | number } = deepmerge(a, b) ``` ### Expected behavior The logic that filters out `undefined` should be reflected in the type even if an optional field is represented via union, and not using a `?`: ```ts const a: { foo: string } = { foo: 'bar' } const b: { foo: number | undefined } = { foo: undefined } const c: { foo: string | number } = deepmerge(a, b) ```