State of `ergo-lib-wasm`

Want to highlight some pain points/things I've encountered while using the wasm library and some suggestions on how I think we might be able to improve the situation. The team probably has a lot of other work/higher priorities but maybe one day we can work on improving the package 😄

**Pain Point: Library size/bloat - `ergo-lib-wasm` is approaching 3mb size, that is really non-trivial for frontend applications in particular**

Possible solution to this could be breaking up the monolithic `ergo-lib-wasm` package into a monorepo/workspaces structure that mirrors the wrapped rust crates and publish each as their own npm package, i.e `@ergoplatform/merkle-tree`, `@ergoplatform/nipopow`, etc.

As an example, I was looking to use NiPoPoW functionality which is a small subset of `ergo-lib-wasm` but in order to do so I need to pull in almost 3MB of extra unneeded code, which greatly impacts one of NiPoPoWs use cases of running on constrained devices

**Library is published as `browser` and `nodejs` versions leaving it up to consumers to try and figure out how to correctly use it in their projects**

Looks like we may have looked into this in the past as we're defining `browser` and `main` fields in `package.json` but still end up publishing 2 packages, it looks like its possible to start publishing as one package, some refs:

- https://github.com/rustwasm/wasm-pack/issues/313
- https://github.com/rustwasm/wasm-bindgen/pull/326#issuecomment-415991338

**API is not ergonomic and doesn't follow JS conventions**

Some examples:

- Functions taking integers require you to perform a dance to convert a JS `number` into a `I64` type
- Collections of types (ie. `ErgoBoxes`, `ErgoBoxCandidates`) being their own types instead of arrays of `ErgoBox` with less functionality than array counterparts make them awkward to work with
- We don't follow JS naming conventions and use `Class.new()` functions instead of constructors, etc

I think exposing an API that makes more use of `js_sys` for types (and then converts them under the hood on the rust side where needed) would greatly reduce awkwardness. For the conventions stuff, making more use of `wasm_bindgen` annotations like `wasm_bindgen(constructor)`, `wasm_bindgen(getter, setter)`, `wasm_bindgen(js_name = renamedToCamelCase)` I think would go a long way to improving usability and making the library more familiar for JS devs