consistently distinguish mapq (mapping quality) from qual (base calling error probabilities)

[dlaehnemann]

This came up in issue #795, opening it here to keep it documented beyond the closing of that issue:

It is confusing when reading the code, that the mapping quality is sometimes referred to as qual, which is also used for the base calling error probabilities in the data field of the bam1_t struct. A suggestion by @jkbonfield is to refactor all instances of the mapping quality to mapq.

[jkbonfield]

We can't easily remove or rename fields without breaking existing code, so this is an htslib 2.0 (no roadmap as yet) feature.

However would accessor functions help clarify this? We could promote use of those and mark internal fields as deprecated maybe.

[dlaehnemann]

I just brought this up as a separate issue to document it, but don't have an urgent need for it to be addressed. So unspecific marking for htslib 2.0 sounds good to me -- milestones, labels, ...? And it's probably best done properly, once, instead of having an intermediate solution that might just create more confusion?