Improve parallelism of search workers
Improve parallelism of search workers

Previously the list of candidates was split between threads a priori,
with each thread being evenly distributed a contiguous range from the
search candidates.

This did a bad job of distributing the work evenly. There are likely to
be areas with significantly more matches than others (ex. files within
directories which match the search terms), as well as areas with longer
strings than others (ex. deep directories).

Because of the type of data fzy receives, work allocation needs to be
dynamic.

This commit changes the workers to operate on the candidates in batches,
until they have all been processed. Batches are allocated by locking a
mutex and grabbing the next available range of BATCH_SIZE candidates.

BATCH_SIZE is currently set at 512, which worked best on my laptop in a
quick test. This will always be a compromise. Small batch sizes will
distribute the work more evenly, but larger batch sizes will be
friendlier to CPU caches.

Quick testing:

Before:
./fzy -e drivers --benchmark < linux_files.txt  1.69s user 0.03s system 163% cpu 1.053 total

After:
./fzy -e drivers --benchmark < linux_files.txt  2.12s user 0.02s system 296% cpu 0.721 total

jhawthorn/fzy,jhawthorn/fzy,jhawthorn/fzy