I think we should overall revisit our use of RichADAMRecord and ADAMRecord. I propose moving to an interface similar to DecadentRead for our internal use, and using ADAMRecord as strictly an I/O format.

My objective with DecadentRead was to create an intuitive and conceptually simple interface to the underlying objects at play. I didn't extend RichADAMRecord nor provide implicit conversions to/from so that accessing the underlying data would be an explicit choice by the programmer, not something that can happen accidentally. The idea is that DecadentRead provides a degree of insulation and checks invariants while providing a simpler interface, saving the programmer from having to know many details of the on-disk storage format (e.g. "you must check `getReadMapped() == true` before relying on `getPrimaryAlignment() == true`, and only then can you look up a `referenceLocation`, but the API will still give you an `Option`, so you have to deal with unpacking that... etc)