feat: reuse worker for same data-fetcher

[manzt]

trafficstars

This PR adds a singleton worker per data fetcher, rather than creating a new worker each time. Ideally, this will allow us to reuse the tile cache for tracks which have the same data source.

I also refactored a bit of bam-worker.ts which was really difficult to follow. This implementation is more clear in my opinion, but there are still many odd bits translating between relative and absolute chromsizes. Ideally we figure out a way to deal with this across all data-fetchers.

[manzt]

This and the recent changes to the workers have started to make those visualizations feel sluggish. I'm not quite sure what is going on, but we should try to improve data fetching generally for our clientside loaders: this only makes the visualization a better user experience.

[sehilyi]

Thanks for this update. I was not sure if this is ready to review, but one issue I found by running an editor on my machine is that the "Fetching... TILE1 TILE2 TILE3 ..." label on a BAM track does not seem to remove already fetched tiles from the list, making the label long after doing some zoom/pan interactions. I spend some time finding the source of this issue, but still uncertain. Somehow, this.fetching does not properly remove already-loaded tile IDs from the HiGlass (https://github.com/higlass/higlass/blob/38f0c4415f0595c3b9d685a754d6661dc9612f7c/app/scripts/TiledPixiTrack.js#L680).

[manzt]

Hmm also can't figure out what is going on here with the HiGlass fetching... It might be overkill to implement this (and perhaps we should just rely on browser caching of requests for now).