Impact of C++20 char8_t on our code

C++20 added the new char8_t} character type and changed the type of {{u8 character and string literals:

• In C++17, u8' ' is a char, in C++20, it is a char8_t.
• In C++17, u8"ä" is a const char[3], in C++20, it is a const char8_t[3].

For Qt, this is both a heaven-sent and hell. It's a heaven-sent, because it gives us a static way to distinguish UTF-8 data. Together with C++17's std::byte, we could now reasonably distinguish binary data (std::byte) from UTF-8 strings (char8_t) and retire char and uchar to legacy status. We don't need the equivalent of QT_NO_CAST_FROM_ASCII for char8_t*, because the conversion is well-defined. It enables QUtf8String (QTBUG-98430). All good stuff.

But it's also hell, because it forces us to re-think our APIs:

1. const char* function arguments break when called with u8"" string literals in C++20
   • needs overloading with a (Q_WEAK_OVERLOAD) const char8_t* version
   • or porting to QByteArray(View), if the data is really supposed to be binary
   • or porting to QUtf8String(View), if the data is supposed to be a string
   • or porting to QAnyString(View), if the overload was part of an all-stringish overload set
2. QByteArray(View) function arguments need to decide what they represent
   • binary? Then ok
   • UTF-8 strings? Then port to QUtf8String(View)!

This very probably is as much work as it sounds.

Come Qt 7, we could go all-in and have