use wasm-bindgen's fs.readFileSync loader in node

[jbr]

This was the end of a long investigation trying to address an issue with the wasm loading from within ts-mocha (use without a compile step). With the included change, we use the wasm-bindgen fs.readFileSync loader, but leave the browser build using the base64-inline loader. I believe this change also resolves the remaining outstanding issues with divviup/divviup-ts#34, allowing a new hpke-dispatch version to be published and used from within divviup-ts through npm.

[divergentdave]

Looks reasonable to me, though I'm not too experienced with wasm-bindgen/wasm-pack. Can we get rid of pkg/node/index.ts at this point?

[jbr]

Yes, I think we can get rid of index.ts, although I wasn't sure if there might still be some use cases for it, as it can be required as import * as hpke from "hpke/pkg/node". Probably best to remove and re-add if we find a need. Unfortunately the wasm packaging state of the art seems to be more tailored towards applications than libraries that hide the use of wasm as an implementation detail.

[jbr]

I'm not entirely sure if this is a breaking change or if it is a patch-level bugfix. As there are likely not a lot of users of this package and it seems like this "works as initially intended," I'm inclined to release this as 03.1 instead of 0.4.0, but am not at all sure of that

[tgeoghegan]

Does the version in Cargo.toml need to be bumped in sync with this?

[jbr]

Previous to #18 there were no changes in the rust interface so it seemed strange to bump the version (and there's no reason the two versions need to be kept in sync) but now there is cause for a minor version bump in both

[tgeoghegan]

OK. I think we should bump the crate to 0.4.0 in this PR, and once we merge it, I'll release 0.4.0 to crates.io.

[jbr]

cd56647