Draft: KConfigPrivate: use QByteArray key API, for no double conversion w/ QString

KConfigGroup supports both QString & const char* types for key. The QString API has been implemented in terms of the const char* one. KConfigPrivate was taking those pointers, to create new QByteArray instances with deep copies from them when calling into the KEntryMap API.

That resulted in double deep QByteArray instance creation with KConfigGroup's QString key API: QString -> toUtf8(), from which the const char* data pointer was taken, passed to KConfigPrivate which then ignored the just created QByteArray, to generate another one.

This patch changes the KConfigPrivate API to take QByteArray references instead, and have KConfigGroup's const char* API already create the QByteArray instances, parallel to the QString ones, This does not change anything effectively for the const char* code path, but allows to pass one the UTF-8 QByteArray created from QStrings, saving another memalloc on every call.

State: first rough version, where things build and tests pass as before.

Further notes: until there is some view-based API, it might make sense to change KConfig API to use QByteArray where currently const char* is used. That allows all the places which currently do not pass some pointer to some literals, but actually taken one from a QByteArray to actually pass that one, saving the deep copy otherwise happening.

To allow convenience code, there could be some template overload taking char[] array and forwarding with a QByteArrayLiteral created in the template code, if that works,