Here we have to break with our previous approach of treating
null variants (NULL in Python) different to invalid qvariants (None in
Python)
There's simply NO way to construct null variants in PyQt6 -- they
are ALWAYS mapped across to Py_None.
This isn't as big a deal as it sounds, we already made the decision
in c++ code to move to invalid variants in favour of null variants.
Note that we STILL need the custom sip code here and can't rely
on base PyQt6 null variant conversion, as that relies on
QVariant::isNull when we must use QgsVariantUtils::isNull so
that the underlying type is correctly checked for null values
on Qt 6 builds.
QVariant::Type does not exist in PyQt6 as its been deprecated
and replaced with QMetaType::Type.
In order to avoid breaking PyQGIS API, we don't want to change
all our functions to use QMetaType::Type instead of QVariant::Type
(that can wait till QGIS 4.0). So instead we leave the c++/Qt 5
signatures as QVariant::Type, but accept QMetaType::Type values
for these functions under Qt 6 builds.
