Remove SAM's artificial 'i' optional field range limit

See motivation in #36 and [samtools#304](https://github.com/samtools/samtools/issues/304#issuecomment-57438913): in short, SAM should be able to represent everything that BAM can represent.

The footnote text at line 860ff originally (see ec8fe9550700fc1d727de52e277faebf4d2e59fc) said

> An integer may be stored [in BAM] as `cCsSiI` depending on the magnitude of the integer. In SAM, all integer types are mapped to `i`.

It was later changed in 598d0141b6cab13afd1f51dc6cf98b815a49827c ("[...] Added BAM tag type "B"; Other format changes and minor clarifications") and ceaff87e7afaef8b754fd6d7ae9354c5a45d2e27 ("Added the B type"; addition of "single") to

> An integer may be stored as one of `cCsSiI` in BAM, representing `int8_t`, `uint8_t`, `int16_t`, `uint16_t`, `int32_t` and `uint32_t`, respectively. In SAM, all single integer types are mapped to `int32_t`.

It seems to me that the SAM sentence's change from `i` to `int32_t` comes under the commit message's category of "minor clarifications" and so the restriction on the range of SAM integers created here is unintended.  So this PR returns the footnote to a clarified version of the original text.

Unfortunately the table in §1.5 has always said that a SAM `i` field is a **32-bit** integer.  IMHO this is not a particularly meaningful thing to say of a textual item, and it seems to me that this has always been a mistake.  So the proposal is to delete this and just describe SAM `i` fields as textual strings of digits, potentially without limit but practically limited by concerns about interchange with the BAM representation.

@tfenne: are you happy with this?  For Java versions with 32-bit signed `int` that don't believe in unsigned, this might cause some implementation difficulties -- but presumably no worse than any difficulties that BAM's `uint32_t` `I` field already causes.