Simplify Null<T> implementation

[lballabio]

• reimplemented Null<T> (both function and class) with constexpr if, which is simpler to read and also more flexible since we can now define a reasonable default for non-numeric types and thus remove the specializations we used to need;
• Array x = Null<Array>() is probably more readable as Array x = {};
• null dates were sometimes written as Null<Date>() and sometimes as Date(), I settled on the latter throughout.

[lballabio]

@pcaspers, may you check (not necessarily before this is merged or before release, no hurry) if this new implementation fixes #1462? If that's the case I would deprecate the configuration switch between function and class implementation. Thanks!

[coveralls]

coverage: 72.676% (+0.003%) from 72.673%
when pulling ef12f99 on simplify-null
into 460a948 on master.

[pcaspers]

I'll try, I have to ask our windows devs if they still have the particular msvc version in use! If you don't hear back on this, please assume there is no problem :-)

[auto-differentiation-dev]

Looks like this caused some issue in Windows with C++17 for us though: https://github.com/auto-differentiation/QuantLib-Risks-Cpp/actions/runs/11174316341

We'll look into it shortly, might be something small / fixable in our code. Curious that it's Windows-only though, and works fine with Windows/C++20.

[lballabio]

Ok, thanks.

[lballabio]

Question—to what does std::is_floating_point_v<Real> evaluate in your setup? And what about std::is_floating_point<Real>::value, which should be the same?

[auto-differentiation-dev]

We provide a standard compatibility header in XAD, which specialises those traits so that the XAD active types behave like the standard floating point types. This allows them to be used seamlessly with the standard library and eases porting existing codebases like QuantLib. We test this on all possible compilers we support to make sure it works smoothly.

The problem with std::is_floating_point_v<T> in MSVC is that its definition is not based on std::is_floating_point<T>, but it uses some internal MS helpers, so it needs explicit handling. But we believe we've fixed that now in this PR - we'll know shortly once this workflow run completes ok.

[lballabio]

Great, thanks.