It's a major refactoring, but paves the way for similar work in
mpileup. When an index is present, this breaks the queries down into
continguous regions and performs consensus fasta/fastq/pileup
generation in parallel.  Each thread independently operates on its own
file descriptor and iterator.

This gives considerably higher multi-threading capabilities than the
old system which simply performed parallel file decompression.
16 threads gives 12-13x speed increase.

More work needs to be done on reference sequence handling, but this is
probably a task for htslib.  Ideally we need a dedicated thread-safe
reference pool that permits ref-incr and ref-decr calls to share
references between multiple threads and tracks those in active usage.
(This exists in CRAM, but needs generalising.)

A few subtle changes occurred during the refactoring too.

- Mpileup and fasta/fastq consensus are now consistent in for
  heterozygous gaps that fail to meet the consensus cutoff.  We prefer
  to call the most likely base now, but will keep quality 0.

  Previously this differed between pileup (which used N) and
  fasta/fastq (which used the most likely non-* base).

- The combination of region queries and whether or not to pad out with
  preceeding Ns for zero coverage is now consistent.  In some cases it
  used to always count from 1 (or region start) irrespective of where
  data coverage was, but did stop early if coverage didn't extend to
  the end.  This sort of half-way -a (all) mode no longer exists.

  Sequence reported is always first observed base to last observed,
  unless -a is used in which case it is 1 to chr length.