Speed up LFtoCRLF by 20% by not scanning all of it for \r\n.

Summary:
The concept of "if it contains \r\n somewhere, don't do anything"
already assumed that the input string was consistent in terms of
newlines. So we can use this to our advantage and only check the first
newline rather than scanning the whole message. Of course this leads to
a different result in some pathological cases like \n on the first line
and \r\n somewhere later, but the assumption is that this can't happen,
right?

Includes a unittest for LFtoCRLF and CRLFtoLF, and a
benchmark for LFtoCRLF.

$ bin/utiltest -perf -iterations 5000

Before:
RESULT : UtilTest::testLFCRLF_performance():
     276,538.3707 CPU cycles per iteration
     0.0790 msecs per iteration

After:
RESULT : UtilTest::testLFCRLF_performance():
     218,439.8416 CPU cycles per iteration
     0.0632 msecs per iteration

The relevance of all this is that I found that 6% of the time was spent
in LFtoCRLF when parsing a very big email in kmail (caveat:
non-optimized build, unlike the above benchmark).

Test Plan:
Tested for a few days with an additional Q_ASSERT(!s.contains("\r\n"));
to see if it would happen that a mail would start with \n and have \r\n later on,
didn't happen (which is no proof of course).

Reviewers: #kde_pim, vkrause

Reviewed By: #kde_pim, vkrause

Subscribers: kde-pim, #kde_pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D13652