Fix | Write DateOnly instances to sql_variant columns of table-valued parameters as date values

[edwardneal]

Description

This builds on #4294, and handles the only other issue I saw while investigating #3934.

If a user-defined table type exists with a column of type sql_variant, client applications can insert a DateOnly instance into this. It's supposed to be sent with a type of date, but is actually sent as a datetime.

Besides a point around correctness, it presents an issue when sending DateOnly instances which are valid values for date but not for datetime: these values overflow.

This PR fixes the issue, transporting all DateOnly instances with the date type on modern .NET. On .NET Framework, there's no DateOnly type - and thus there's no way for the client to encapsulate a date value within a sql_variant column.

@ErikEJ, this covers the only other way to write DateOnly instances to SQL Server and should hopefully completely close #3934. SqlClient will continue to read DateTime instances by default, but this is needed for backwards compatibility purposes.

NB: similar issues also exist with TimeOnly instances. TdsParser assumes that only TimeSpan instances will be written as times, so there are failures to cast in a few different places.

Issues

Builds on #4294. Possible resolution to #3934.

Testing

#4294 added the relevant tests, with an exemption carved out for this use case. I've removed the exemption and verified that it covers the test case.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.