Ensure bam->cram->bam roundtripping is completely lossless

[cmnbroad]

This is related to #455, but we also need to add tests to verify this in general. Specifically, we need to ensure that the NM tag is regenerated using the same algorithm used by Picard. It looks like the CRAM code is using SequenceUtils.calculateMdAndNmTags (with restoreMD set to false), whereas it looks like Picard is using SequenceUtils.calculateSamNmTag. Need to verify this.

[yfarjoun]

currently Picard's SamFormatConverter doesn't generate a PIcard-valid sam since the NM tag is missing.

[cmnbroad]

@yfarjoun Do you have more context for this SamFormatConverter issue ? It looks to me like Picard is just delegating to htsjdk to do the conversion, so (with the changes we made in #487) it should be restoring whatever NM tag value was there when the file was originally converted to CRAM.

[yfarjoun]

OK. perhaps it is now working.

[cmnbroad]

Remaining known issues:

#499 (unsigned attributes)
#713 (cigar element transformations)
#714 (lossy values for unmapped reads)
#509 (legacy issue that only affects version 2.1 CRAMs created with old htsjdk code)