RFC: Perf: Use QHash everywhere (changes public API -> so something for Qt6?)

Quite a few times when profiling FatCRM I noticed the expensive insertions into QMaps while parsing VCards inside the KContacts library. Checked that a bit more thoroughly: Seems like we do not necessarily need KContacts to use QMaps internally at all, thus this patch here.

Needs a few changes inside VCardTool::parseVCards as the order of the identifiers is now arbitrary. The label-assignment inside this method depended on the "LABEL" identifier being processed after the "ADR" identifier, that no longer works obviously, so the label-assignment needs to be done at a later stage now.

Warning: Changes public API: Now there's QHash being used instead of QMap basically everywhere.

Performance gain is roughly around ~14% according to no. of instructions. See benchmarks below.

BENCHMARK BEFORE THIS PATCH:

Performance counter stats for './bin/vcardtool_benchmark' (5 runs):

        623,80 msec task-clock                #    0,999 CPUs utilized            ( +-  0,63% )
            19      context-switches          #   30,138 /sec                     ( +- 48,33% )
             1      cpu-migrations            #    0,962 /sec                     ( +- 40,82% )
           783      page-faults               #    1,255 K/sec                    ( +-  0,35% )
 2.604.172.545      cycles                    #    4,175 GHz                      ( +-  0,33% )
 4.499.606.209      instructions              #    1,73  insn per cycle           ( +-  0,01% )
   762.527.353      branches                  #    1,222 G/sec                    ( +-  0,03% )
     3.476.746      branch-misses             #    0,46% of all branches          ( +-  0,95% )

       0,62451 +- 0,00406 seconds time elapsed  ( +-  0,65% )

BENCHMARK AFTER THIS PATCH:

Performance counter stats for './bin/vcardtool_benchmark' (5 runs):

        536,36 msec task-clock                #    0,999 CPUs utilized            ( +-  0,29% )
             8      context-switches          #   14,169 /sec                     ( +-  6,71% )
             0      cpu-migrations            #    0,746 /sec                     ( +- 61,24% )
           784      page-faults               #    1,461 K/sec                    ( +-  0,31% )
 2.238.016.622      cycles                    #    4,173 GHz                      ( +-  0,33% )
 3.853.019.711      instructions              #    1,72  insn per cycle           ( +-  0,42% )
   662.154.395      branches                  #    1,235 G/sec                    ( +-  0,37% )
     2.634.433      branch-misses             #    0,40% of all branches          ( +-  0,68% )

       0,53674 +- 0,00159 seconds time elapsed  ( +-  0,30% )