Impact of new C++20 attributes on our code

C++20 added four new attributes:

1. likely
2. unlikely
3. nodiscard("reason")
4. nodiscard on ctors
5. no_unique_address

For the first two, we already have macros Q_LIKELY and Q_UNLIKELY. There's some sense in porting their implementations to the C++20 attributes, when available. But that's not something that affects API in any way.

For the third, we've just ported all our Qt 5 Q_REQUIRED_RESULT to [[nodiscard]] in Qt 6, so it's unlikely that we'll go back to a Q_REQUIRED_RESULT_X("reason"). We'll see.

For the fourth, I believe we already have a macro, if not, then we should add one, and apply it to RAII type's ctors, because it's the better option over our current technique of declaring the whole RAII class [[nodiscard]], because while Clang 10 warns on QMutexLocker<QMutex>{&mut}, GCC 12 does not, w/o the [nodiscard]] on the ctor. Also, this could be a perfectly-valid use of QMutexLocker, but it's currently disabled d/t the class-level [[nodiscard]]: QMutexLocker<QMutex> fun(~~~); (void)fun();.

[[no_unique_address]] is very interesting, as it allows, effectively, zero-sized objects, something for which one so far had to use EBO (Empty Baseclass Optimization). So, theoretically speaking, we could replace all our EBO uses with [no_unique_address], but that would not be compatible with C++17, so cannot be done until we have moved to C++20 as the minimum version.

There were some ideas to use [[no_unique_address]] to mimic C# properties in C++ floating around at some point, but a) we just introduced a new C++ property system in Qt 6, and b) you cannot rely on [[no_unique_address]] to enforce a zero-sized object. It's mostly useful for storing allocators in containers and similar situations.