Perf: Improve perf of SqlDateTimeToDateTime

[Wraith2]

While reviewing #853 I did some digging into the related code and profiling. The function used to convert sql date times to .net datetimes came up as hot so I tinkered with it a bit. The most important part is to avoid creating a datetime just to get a constant value from it, hardcode it instead.

Gist of the benchmark code is here: https://gist.github.com/Wraith2/d0d220f07e640c17daeb9db2d446aaa4

results:

BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19042
Intel Core i9-9900K CPU 3.60GHz (Coffee Lake), 1 CPU, 16 logical and 8 physical cores
.NET Core SDK=5.0.200-preview.21079.7
  [Host]     : .NET Core 3.1.12 (CoreCLR 4.700.21.6504, CoreFX 4.700.21.6905), X64 RyuJIT
  DefaultJob : .NET Core 3.1.12 (CoreCLR 4.700.21.6504, CoreFX 4.700.21.6905), X64 RyuJIT

Method	Mean	Error	StdDev	Ratio
Original	271.50 ms	4.619 ms	4.321 ms	1.00
New	82.45 ms	0.232 ms	0.206 ms	0.30

/cc @bjornbouetsmith who this may interest

[cheenamalhotra]

Seems thr's a test failure you may want to take a look:

System.OverflowException : SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.
...
   at Microsoft.Data.SqlClient.ManualTesting.Tests.DateTimeTest.ReaderParameterTest() 
... ManualTests\SQL\DateTimeTest\DateTimeTest.cs:line 188

[Wraith2]

Nice catch. Didn't see it among the other CI failures.
Reworked slightly to deal with the bounds and I've added a uint range check trick that wasn't worth using before (regressed it by 4%) but now does seem worthwhile. The range checks work by knowing that negative integers cast to extremely large positive uints so if we do zero based checks we only have to check 0 to max and not a min check.

Method	Mean	Error	StdDev	Ratio
Original	258.05 ms	2.267 ms	2.010 ms	1.00
New	85.68 ms	0.589 ms	0.551 ms	0.33