Use htsFormat to replace htsFile's is_foo flags

Add an htsFormat member to htsFile, readable via hts_get_format().
Use hts_detect_format() within hts_hopen(fname, "r"), and fill in the
format based on mode letters for "w".

The htsFormat settings are clearer than the old is_foo flags, so begin
recoding SAM/BAM/CRAM and VCF/BCF tests to use fp->format.format (within
htslib; hts_get_format(fp)->format elsewhere) instead.  However several
of the flags are used directly outside htslib (see notes in htslib/hts.h)
so even though they are unused within htslib they cannot be removed
unless/until libhts.so's soversion is changed.

The is_be, is_compressed, and is_kstream flags are not used in samtools
or bcftools and we assume they are not used in other third-party code,
so they are safe to remove (and is_kstream has been removed).
Add htsfile utility

Note that hts_format_description() may possibly need to change to return
a string that the user must free() before release.  Manpage to follow.
Merge origin/develop, replacing htsFile.type by .format

Use the followups mentioned in abd1efb rather than the alternatives
via htsFile.type -- in particular, retain is_cram for the sake of
libhts.so binary compatibility.  The -i option added to tabix now
duplicates htsfile functionality, and can be removed in due course.
Parse SAM aux 'i' values > 2^31 correctly

BAM can represent 'i' values from -2^31 and 'I' values up to 2^32-1.
Especially on machines where long is 32 bits, we need to consider
positive and negative values carefully and separately to parse this
whole range correctly.

Addresses samtools/hts-specs#36 -- even if the spec doesn't require
this (which may soon change), as a quality of implementation issue
htslib should support the same range in SAM and BAM.
Sped up cram_index_load some 200 fold by replacing sscanf with our own
number decoding.
Fixed an incorrect EOF-style case when seeking multiple times.

When asking to fetch data for a specific chr:range, if the current
container entirely fits within the range but the next container is
outside the range then it sets the fd->ooc (out of containers) flag to
prevent subsequent containers from being decoded, to mark the end of
the sub-query.

However this then causes a subsequent cram_seek to also fail as the
ooc flag is still set. We now clear this on every new seek.
Fix of memmove bug in bcf_remove_filter()