feat: Upgrade to Gosling v0.9.31

[manzt]

Changes:

• Bumps Gosling.js to v0.9.31
• adds gos.bed as a top-level API

TODO:

Need to test out some BED examples. I'm noticing that BED only seems to work for indexed BED files? If BED file isn't indexed, should users prefer the csv loader? @sehilyi @etowahadams

[etowahadams]

I'm noticing that BED only seems to work for indexed BED files? If BED file isn't indexed, should users prefer the csv loader?

Similar discussion in #764 (comment) with respect to VCF and GFF files. It seems like the tentative decision was to require indexing so I followed suit for BED files.

I think it would be nice to also support unindexed files through the BED fetcher API, if the file is small. Currently the only way is through the CSV data fetcher. Is this something we would want to prioritize?

[sehilyi]

I agree that it would be good to support unindexed BED files as well using the bed type data specification. But, given that it is still possible to load them through the CSV data fetcher, I think it is a lower prioritization than implementing other currently unsupported data fetchers.

[manzt]

But, given that it is still possible to load them through the CSV data fetcher, I think it is a lower prioritization than implementing other currently unsupported data fetchers.

I agree with the focus on priorities, but I'm concerned that mandating indexing for BED files might confuse/frustrate end users (especially since I don't see BED support documented in Gosling.js). If I had a .bed file, I'd expect to use gos.bed (or type="bed") to load my data. Knowing that CSV works requires an understanding of the underlying file format. It's important to note that we support a variant of BED that isn't formally described in the spec: BED + index.

For a large number of features, I agree that indexing should be preferred. But requiring tabix-ing files that are totally reasonable to load into memory in order to use designated data loader is a lot of friction.