Check number syntax is valid in hts_parse_decimal()

[jmarshall]

Motivated by #1395, this alters hts_parse_decimal() to validate that the number parsed is indeed a validly presented numeric value and to have a way of reporting failure. What we want to accept and the returned strend value are carefully considered, and test cases are added accordingly.

Follows strtol() et al's conventions, setting strend to the original str (or emitting a warning if strend is NULL) if the input string does not form a valid numeric constant. In particular, require it to have a non-zero number of digits.

Merges E and k/M/G handling, so that at most one can be used. In particular, "1e+3k" is non-standard and ambiguous, and should be rejected.

Adds documentation to htslib/hts.h describing the numeric syntax parsed and the two modes of operation (as determined by whether strend is NULL or not).

Add test cases, in particular verifying that a sole "G" is rejected. Fixes #1395. For simplicity, the tests are added to test/sam.c which already contains similar API tests. If preferred, I could create a new test/hts.c containing these tests instead.

[jmarshall]

Rebased past PR #1396, which has since been merged.

IMHO this PR further improves hts_parse_decimal() over current develop, by carefully considering how the returned strend value can be used by the caller to detect failure and by considering the diagnostics that should be emitted in the strend == NULL mode of operation. In particular, current develop's early return for the !has_digit case:

• does not emit a diagnostic (in strend == NULL mode) when no valid number has been parsed, which would be the user's only way of noticing the problem in this mode.
• does not return a strend value that can easily be used to detect parse failure when the string begins with whitespace (as str has already been incremented past the whitespace, so the returned *strend is not equal to the caller's str).

[daviesrob]

Looks good, thanks.