WIP: Improved async api for arrow1

No need for content length (closes https://github.com/kylebarron/parquet-wasm/issues/272). I was able to verify in the browser console a fetch for Range: bytes=-8 and then secondly Range: bytes=-9772 for the full metadata (testing in this notebook).
Merge adjacent byte ranges into a single request (Closes https://github.com/kylebarron/parquet-wasm/issues/392). I was able to see that table = await parquetFile.read_row_group(0) made just a single request!
New class-based API with AsyncParquetFile (for https://github.com/kylebarron/parquet-wasm/issues/215). I think this is cleaner and easier to use, and on the Rust side the only data stored in the class is the file metadata, arrow schema, and reqwest client. So if the user forgets to call .free(), not a ton of memory will leak.

[ ] Use this API automatically under the hood for streaming
[ ] Concurrent row group fetches? Or should I leave that to the user to call Promise.all from the JS side? It's probably non-trivial to implement support for this in wasm
[ ] Ability to turn off arrow's re-chunking creating batches of 1024 rows by default is way too small imo.

cc @H-Plus-Time

kylebarron / parquet-wasm