Unify and optimize QByteArray::to{Upper,Lower}

Do a check first if we need to transform before doing the transform.
This means we won't detach when transforming data that is already
correct.

And instead of using QChar, use our own hand-rolled table. In a proper
LTO build, the QChar calls would be resolved to a lookup of the Unicode
data, but not many people do LTO builds, Therefore, this means a great
speed-up is achieved by simply avoiding the function call. The extra
gain in performance comes from the simpler translation table instead of
the more complex full-Unicode data.

Also as a consequence, this changes the handling of two characters in
Latin 1: 'ß' should be uppercased to "SS" but we won't do it, and 'ÿ'
can't be uppercased in Latin 1 ('Ÿ' is outside the range).

Benchmarking is included. Comparing the Qt 5.4 algorithm to the new code
is almost 20x faster. Other alternatives are included in the benchmark
and are all faster than the current code, though slower than the new
one. While all of them could compress the tables to be smaller or shared
between uppercasing and lowercasing, they would also expand to more code
(though probably less than the extra bytes required in the full
translation table). In the trade-off, I decided to go with simplicity
and most efficient code.

Change-Id: I002d98318d236de0d27ffbea39d662cbed359985
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Optimize qstricmp()/qstrnicmp()

The latin1 conversion tables that were recently introduced to qbytearray.cpp
to speed up QByteArray::to{Upper,Lower}() can also be used in qstr(n)icmp.

This results in speedups between ~2 for strings with differences in the
first char, to almost 10x for strings with differences only after 8k of
data.

Change-Id: I878ddb4c01c798069d439a9d33e24351fe1039d3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Add rvalue-ref qualified overload of QByteArray::to{Upper,Lower}

Those operations aren't very common with QByteArray but this is easy to
optimize.

                Qt                   Qt Creator
        const &         &&      const &         &&
toLower      34         10            0          1
toUpper       3          1            0          0

Change-Id: I2097955f4c889ea5a21903c35ddbc0ff27bf62c5
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Unify and refactor QString::to{Upper,Lower,CaseFolded}

This unifies the code for those three functions in one refactored
template function, using QStringIterator. I don't think there's any loss
of performance by doing that refactoring -- this is based on my reading
of the disassembly, without running any benchmarks.

Change-Id: I5893c6ed47462c473886c722a21577b1e8a23841
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Add rvalue-ref qualified QString::to{Upper,Lower,CaseFolded}

This is even more common than the QByteArray equivalents.

                Qt                   Qt Creator
        const &         &&      const &         &&
toLower      71         50           45         26
toUpper      35          8           46         35

Change-Id: I8b797d2321b22ce414c23656c5f1709ac649c423
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Simplify and unify Q{ByteArray,String{,Ref}}::{simplify,trimmed}

As a side effect, QString::simplified() will always return a detached
copy, even if it's the same contents.

QStringRef::trimmed() can use the same calculation algorithm but can't
use the trimmed_helper() template function due to its lack of a
constructor taking begin pointer and size (std::string_view could do
it). That constructor can't be added because QStringRef always refers to
an existing QString, not to data in memory.

Change-Id: Ib966c1741819c68c6bac5fcbb00f8ac818b3ccab
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
QString: replace an inefficient QList with QVector

qt_section_chunk s larger than a pointer and wasn't marked as movable,
so holding it in a QList is horribly inefficient.

Change-Id: I32162b4960d32674a1f3b05bc24ac8813f16638d
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>