Rewrite BAM auxiliary data

[jakobnissen]

This is the first step towards improving the API and performance of XAM.jl.

This PR is not breaking. It introduces a new data type representing BAM auxiliary data. When this PR is done, it will introduce a new function that allows users to manipulate auxiliary data using this new type.
The old type may then be removed in a future, breaking version of BAM, if one such is ever to happen. So, if this PR lands, and I never get around to make larger changes to XAM, or we disagree on what to do, this PR should still be a win :)

The advantage of this new AUXData type over the old AuxData is:

• It allows both reading and writing, whereas the old only allowed reading
• It's faster
• It's more type stable
• It conforms more closely to the AbstractDict interface.

The design of this currently relies on there never being any extra noncoding bytes in BAM record's data vector. However, there currently sometimes are.
Why the change? In older versions of Julia, resizing vectors were always slow. So, significant time could be saved by having the vector be overly long, and then storing the true length as an integer inside your mutable struct. However, from Julia 1.11, simply resizing the vectors is now even faster :)

TODO

• Change BAM record to never have unused bytes at the end (Do not allow unused trailing bytes in BAM records #71)
• Integrate with existing BAM, and provide a good API
• Add tests
• Add actual useful error messages
• Review TODOs in code

[kescobo]

introduces a new data type representing BAM auxiliary data. When this PR is done, it will introduce a new function that allows users to manipulate auxiliary data using this new type.
The old type may then be removed in a future, breaking version of BAM, if one such is ever to happen.

Based on this description, this modification is strictly additive. To me, having an AuxData and an AUXData is confusing, and since we're still pre-1.0, I'd kinda prefer just making another breaking release (even though the last such release was in January).

Aside from the name change, how much is different between the old and new types?

[CiaranOMara]

Don't changes in the length of BAM.Record.data need to be reflected in BAM.Record.block_size?

[CiaranOMara]

Naively, once the span is found, couldn't splice! be used to adjust BAM.Record.data?

function adjust(record::Record, indices, newdata::Vector{Uint8})
    splice!(record.data, indices, newdata)
    record.block_size = recalculate_block_size(record.data)
end