SAM: "next" vs "next primary".

[jkbonfield]

For RNEXT and PNEXT fields we explicitly state the next primary alignment. It is a bit unclear what the interpretation of these fields on a secondary alignment, but that's not a big issue.

For FLAG field the 0x8 and 0x20 bits mention "next segment" with no qualification of it being the next primary segment. Clearly we need primary data as if we are looking at the first read in a pair then we use FLAG, RNEXT and PNEXT jointly to obtain information about the "other end". If RNEXT/PNEXT refer to the other end but FLAG may potentially not then these fields lose their usefulness.

I believe the table of bits in 1.4 should be modified as s/next segment/next primary segment/;

[nh13]

This would also align with changes we have made in supporting CRAM.

[jkbonfield]

See also #53 for a more detailed commentary on this.

It is my current feeling that while there is an ambiguity between PNEXT/RNEXT and FLAG regarding primary vs non-primary attributes, the whole concept needs a revision and we should permit RNEXT/PNEXT/TLEN for self-consistent secondary mappings too.

Either way FLAG has to be one of the places the text is changed as it is part and parcel of the pnext/plen/tlen/flag quadvector.