Document the ambiguity of 1-base long seq with QUAL *

[jkbonfield]

This is an extreme edge case likely to never occur, but nevertheless tool implementors still need to know how to handle it. Given it may be QUAL 9 or it may be QUAL "unknown", we treat it as always unknown.

Fixes #715

[github-actions]

Changed PDFs as of cca15e8: SAMv1 (diff).

[github-actions]

Changed PDFs as of 7915c3d: SAMv1 (diff).

[jmarshall]

I have finally got around to finishing up my draft of adjusting this footnote. (The diff PDF preview has gone slightly mad — the actual change is the new footnote 17 on page 9.) It's been so long that I can't remember the details, but this is a tidied-up version of the text lying around in my specs directory after discussions on this one in meetings a few months ago.

The changes are basically:

• Avoid referring to this as ambiguous — now that the spec provides a ruling (albeit in a footnote), it's not ambiguous.
• I think we discussed offering advice on what tools should do if they have a single-base QUAL of 9 to write out. The second sentence does so, and says do it for all of SAM/BAM/CRAM to avoid issues later when BAM/CRAM files are viewed as SAM. But I'd also be happy if you preferred to drop that and just have the first sentence for succinctness.

[jmarshall]

On the merged commit, @colinhercus comments (f7809ca#commitcomment-162178132):

In this situation Novoalign has always reduced the base quality to 8. I don't plan to change it.

(The PR recommends adjusting the base quality to 10.)

I wish you'd noticed this updated PR in the month before we merged it… 😄 Or in the two years since the issue was first noted as an issue on this repository… 😄 😄

I thought of looking to see if any of the base quality binning strategies used either 8 or 10 or a nearby value, but in the end we picked 10 arbitrarily. Do you recall whether you picked 8 arbitrarily or was there some reasoning behind the choice?