Add mismatches cache to improve performance on ultra-long reads

[cmdcolin]

here is a summary of the problem in google slide form

When each block renders, the renderer e.g. PileupRenderer requests features using the data adapters getFeatures method

Currently, the BAM library (@gmod/bam) has a feature cache to avoid re-requesting from the actual remote file each time, but JBrowse 2 re-creates new instances of e.g. the BamSlightlyLazyFeature from scratch each time.

This leads to duplicated computation of e.g. the "mismatches" on BAM and CRAM are not cached across blocks. This particularly affects long reads

This PR adds a method to cache the mismatches object by making a simple LRU cache that avoids re-creating an already created feature. it is not an "async LRU" so it is easy to reason about

[cmdcolin]

alternative approaches considered: this PR caches the record on the JBrowse wrapper around the @gmod/bam BamFeature class. we could have considered caching on the @gmod/bam BamFeature class directly, but there is some amount of setup the the JBrowse wrapper does such as integrating it with the underlying reference sequence that the @gmod/bam "has no knowledge of" but which is quite important for calculating mismatches in many cases (e.g. when there is no MD tag)

[cmdcolin]

note that this PR is somewhat similar to the "cacheMismatches" feature added somewhat late in the game to jbrowse 1 cacheMismatches

[cmdcolin]

this PR basically has no effect on short and even medium length long reads but does have an effect on ultra long reads

60x nanopore ultralong reads

ultralong reads are e.g. 300kb on average. when it has to repeatedly parse the large CIGAR string for these reads to find mismatches it is a bit slow

live demo

• main https://jbrowse.org/code/jb2/main/?config=test_data%2Fconfig_demo.json&session=share-O1hBztTbTk&password=33BS3
• this branch https://jbrowse.org/code/jb2/feature_cache/?config=test_data%2Fconfig_demo.json&session=share-O1hBztTbTk&password=33BS3

I don't have a benchmark for zooming in and out but it can be like 4-8 seconds to zoom in and out the ultralong reads on main, but it's about ~1 second with this branch

notably, on other datasets including even medium length pacbio reads and short reads, it is basically no effect. this suggests the cache could be kept exclusively for use with only ultralong reads but it might not be necessary