Support range requests

[hannahhoward]

Goals

Support range requests in the client. For now, only supports one HTTP range (FWIW, the HTTP range spec allows multiple ranges to be specified -- I don't think that gets used for video and audio)

Implementation

So it turns out ipfs-unixfs-exporter already has range support of a kind -- when you call node.content() you can pass ExporterOptions object with and offset and length, and it will properly return the right data, loading the correct blocks. (I think)

What is needed then is just to do the right parsing -- http ranges are pretty weird -- they support negatives and also missing end values.

This adds a range property to the FetchOptions that has a rangeStart and rangeEnd parameter, which should correspond to the integer values in the range parameter (i.e. 'bytes=0-1000' becomes {rangeStart:0, rangeEnd: 1000})

There are two things to do with this parameter

1. pass it to the L1's as entity bytes -- so you get the right blocks in the response.
2. Convert to offset/length params on unixfs-exporter to do ranged verification

Next steps

I've made a similar change to actually read the range header in the service worker (PR incoming).

This should be a complete solution from a raw implementation standpoint, but it needs further testing. There are unit tests of the changes, but little integration testing.

In particular, the UnixFS exporter range requests are tested against a single block file. We need to make a test that verifies it works with a multi-block file.

We also probably need a round trip integration test that verifies we can make a request (fetchContent or fetchContentWithFallback) with the range option set, and the expected URL will go to the backend, and given the proper car response, it verifies.

The good news is I believe, at least tentatively, that we can make this all work without getting into unixfs-exporter code.