This extends the callback function used by the hts iterator code to
the ref:start-end range parser, permitting the parser to validate
whether the whole thing matches a reference name.

This works around parsing conflicts when given range queries like
"HLA-DRB1*12:17", which is either the whole of "HLA-DRB1*12:17" (this
exists in GRCh38) or base 17 onwards of ""HLA-DRB1*12" (which does
not).

Note there are still some undecided questions here.  Do we want to
handle the special names used in the iterator at this level to?  Eg
"*" meaning unmapped data and "." meaning whole file?

Also improved return values so NULL is primary way of detecting
failure rather than tid.  This is more in line with the old
hts_parse_reg code.

See samtools/hts-specs#124 (comment)
for heuristic suggestions.

Eg with contigs named "chr1" and "chr1:100-200" we can specify
"{chr1}:100-200" and "{chr1:100-200}" to disambiguate.

The old function (hts_parse_reg) has been put back, meaning the new
API can now have the getid func pointer as a mandatory requirement.

Added tests.

Tweaked sam_parse_region to have the flags parameter.  This is still
required as bcftools and samtools use different parameters (parsing
style is tool based rather than file format based).

Previously it had its own custom parser which nearly, but not quite,
matched the old hts_parse_reg code in functionality.

Note this changes the fasta coordinate type from long to int, which is
a backwards step.  However it is expected this will subsequently
change to hts_pos_t in another PR.

Mainly copied from the useful (but not so visible) comment
before the function definition in hts.c.

Hash table can now use tid (cast to khash32_t, which is unsigned)
as key instead of the region name, avoiding some string copying.