Add Unitful tests for constant extrapolation

[Ickaser]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

After 7.0 (which made good changes), the extrapolation procedures are not kind to Unitful numbers.

MWE:

t = range(0.0u"s", 10.0u"s", length = 11)
P = exp.(t/u"s")*u"W"

P_interp = ConstantInterpolation(P, t; extrapolation=ExtrapolationType.Constant)

P_interp(11u"s")

Without this PR, this produces a DimensionError:

ERROR: DimensionError: 1.0 W and 0.0 s W are not dimensionally compatible.
Stacktrace:
 [1] +(x::Quantity{Float64, 𝐋^2 𝐌 𝐓^-3, Unitful.FreeUnits{…}}, y::Quantity{Float64, 𝐋^2 𝐌 𝐓^-2, Unitful.FreeUnits{…}})
   @ Unitful C:\Users\iwheeler\.julia\packages\Unitful\nwwOk\src\quantities.jl:137
 [2] _extrapolate_left(A::ConstantInterpolation{…}, t::Quantity{…})
   @ DataInterpolations C:\Users\iwheeler\.julia\dev\DataInterpolations\src\interpolation_methods.jl:17
 [3] _interpolate
   @ C:\Users\iwheeler\.julia\packages\DataInterpolations\5Uosd\src\interpolation_methods.jl:3 [inlined]
 [4] AbstractInterpolation
   @ C:\Users\iwheeler\.julia\packages\DataInterpolations\5Uosd\src\DataInterpolations.jl:27 [inlined]
 [5] (::ConstantInterpolation{…})(u::Vector{…}, t::StepRangeLen{…})
   @ DataInterpolations C:\Users\iwheeler\.julia\dev\DataInterpolations\src\DataInterpolations.jl:56
 [6] (::ConstantInterpolation{…})(t::StepRangeLen{…})
   @ DataInterpolations C:\Users\iwheeler\.julia\dev\DataInterpolations\src\DataInterpolations.jl:31
 [7] top-level scope
   @ c:\Users\iwheeler\OneDrive - purdue.edu\Documents\LyoResearch\LyoPronto.jl_NIIMBL\scripts\mwe.jl:12

A related bug that prompted this involved typed_nan not having a definition for Unitful quantities, which is why I expand it to <:Number, not just <:AbstractFloat

(This PR was prepared in a hurry while I was distracted. Will take a second look later on and make sure this is consistent throughout.)

[ChrisRackauckas]

Needs tests or this is guaranteed to regress.

[Ickaser]

Some of what prompted this would also be fixed by #379 , I suspect. I'll give that attempt a little time to merge, so this can be rebased on that, but I will plan to at least use this PR to add some tests for a reasonable set of behavior (e.g. at least the extrapolated values, if not the derivatives).

[DaniGlez]

Yeah, at a first glance the error-triggering operation from here does not appear in the refactor from #379. The current slope-based mechanism seems to be the source of both the type-inconsistency motivating this one and also the one in #378

[ChrisRackauckas]

Literal unit tests