Fix bam readcount

Previously, we were encoding one bam-readcount entry per sample in each vcf entry.  This doesn't fully reflect the reality of the relationship between vcf entries and bam-readcount entries, since one vcf line might contain multiple alleles that are best represented by multiple bam-readcount entries (e.g. an insertion and a deletion on the same line).
Here, we change how bam-readcount lines are encoded in the vcf to accomodate per-allele bam-readcount entries.
When this goes live, we'll need to set test names on all software results of type Genome::VariantReporting::Suite::BamReadcount::AnnotateResult so that they are regenerated with the new encoding.
This doesn't distinguish between deletions and complex substitutions of shorter length which may or may not be padded (e.g., ACTT => TCT, ACTT => G). In the context of bam-readcount, relying on this to figure out which base contains the first of interest is not sufficient. vcfallelicprimitives can break apart some but not all of these cases. It would be better to not ask questions like "is this a deletion" and instead to ask "which reference bases/gaps are being edited by this variant".