[datetime2] fix: non-nullable onChange adapter

[adidahiya]

Changes proposed in this pull request:

It's common to see code like this in a function component using DateInput:

const handleChange = React.useCallback((newDate: Date) => {
    // ...
}, [/* some dependencies */]);
return <DateInput2 onChange={handleChange} />;

When this gets migrated to DateInput2 using our automated codemods, it becomes:

const handleChange = React.useCallback((newDate: Date) => {
    // ...
}, [/* some dependencies */]);
return <DateInput2 onChange={DateInput2MigrationUtils.onChangeAdapter(handleChange)} />;

... which nullifies the benefits of useCallback since a new function is being created every time. A better pattern would be:

const handleChange = React.useCallback(
    DateInput2MigrationUtils.onChangeAdapter((newDate: Date) => {
        // ...
    }),
    [/* some dependencies */]
);
return <DateInput2 onChange={handleChange)} />;

... but that did not type check before this PR because of the loose input/output types for the adapter which included undefined.

This change fixes the type of DateInput2MigrationUtils.onChangeAdapter so the last code example works.

[blueprint-bot]

[datetime2] fix: non-nullable onChange adapter

Previews: documentation | landing | table | demo