QStringView: refuse construction from QStringRef

When QStringRef was moved out of QtCore, it was also incorrectly
removed from the if_compatible_container constraint, causing
QStringView{sr} to still match the general container QStringView ctor
overload, which doesn't preserve null'ness if data() doesn't return
null. By refusing to provide a constructor from QStringRef, we force
the compiler to use QStringRef's implicit conversion operators
instead.

This transitively affects QAnyStringView in the same way.

The tests can, naturally, only be in qt5compat, so define a macro to
communicate to tst_QStringRef whether it compiles against a fixed
QtCore or not.

Fixes: QTBUG-122797
Fixes: QTBUG-122798
Pick-to: 6.8 6.5
Change-Id: I64b75a8e421d2b6185615e3288ce3ad7fd8f15f9
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
(cherry picked from commit a0e65398483729259cf58781949133c6055fdc7c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>

src/corelib/text/qstringfwd.h

@@ -36,6 +36,7 @@ class QLatin1String;
 using QLatin1StringView = QLatin1String;
 #endif
 class QString;
+class QStringRef; // defined in qt5compat
 class QStringView;
 template <bool> class QBasicUtf8StringView;
 class QAnyStringView;

src/corelib/text/qstringview.h

@@ -64,6 +64,8 @@ struct IsContainerCompatibleWithQStringView<T, std::enable_if_t<std::conjunction
 
             // These need to be treated specially due to the empty vs null distinction
             std::negation<std::is_same<std::decay_t<T>, QString>>,
+#define QSTRINGVIEW_REFUSES_QSTRINGREF 1
+            std::negation<std::is_same<q20::remove_cvref_t<T>, QStringRef>>, // QStringRef::op QStringView()
 
             // Don't make an accidental copy constructor
             std::negation<std::is_same<std::decay_t<T>, QStringView>>