Update dependencies (#314)

* feat: update `polkaj-schnorrkel`

- adds the new VRF functionality
- jar built at this commit: LimeChain/polkaj@3327211

* feat: update `wasmer-java`; add more targets

- add a fresh build of wasmer-java at LimeChain/wasmer-java@cb4fafe

- add more target platforms (+linux and windows)

* chore: add some known todos to `TODO.md`

README.md

@@ -46,8 +46,8 @@ export JAVA_HOME=`/usr/libexec/java_home -v 17.0.8`
 Note: This step will be automated in the future
 ```
 
-Depending on your architecture type, you will have to grab one of either 2 versions(arm/amd) of the wasmer-java dylib
-file from `wasmer-setup` folder.
+For now, you will have to manually grab the compiled `wasmer-java` dynamic library
+file from the subfolder under `./wasmer-setup` corresponding to your architecture type.
 Copy the file to the Java `Extensions` folder:
 
 ```

src/main/resources/TODO.md

@@ -7,4 +7,7 @@
   So: map the CLI argument to an ENUM instance and from there: 
   - in production, use `application.properties` to fetch the chain spec path;
   - in test, use another properties file (spring profiles could help) or implement local test-case specific map from enum to paths... something like that
-- Add exception handling (Error Resolver while creating the JSONRPC server) for RPC calls, as currently we are leaking classpath to the exceptions and not using the suggested error codes from the JSON-RPC spec. Look into (./libs/jsonrpc4j-1.6.2-SNAPSHOT.jar!/com/googlecode/jsonrpc4j/JsonRpcBasicServer.class:468)
+- Add exception handling (Error Resolver while creating the JSONRPC server) for RPC calls, as currently we are leaking classpath to the exceptions and not using the suggested error codes from the JSON-RPC spec. Look into (./libs/jsonrpc4j-1.6.2-SNAPSHOT.jar!/com/googlecode/jsonrpc4j/JsonRpcBasicServer.class:468)
+- Revisit the conversations on the VRF proofs PR from within PolkaJ's Schnorrkel wrapper [here](https://github.com/LimeChain/polkaj/pull/2). Goal: we're waiting for potential upgrade of `robusta` to a newer jni to refine the ugly hacks in our solution. More details in the PR conversation.
+- Make `wasmer-java` load the native libraries as dynamic libs and remove the need for manual intervention for the user from [the README](https://github.com/LimeChain/Fruzhin/blob/dev/README.md#wasmer-java-dylib-setup). In other words, add the mentioned "automation later" :D
+I'd suggest a similar approach to what's in `polkaj-schnorrkel`, still not ideal for the dev, but definitely better for the user.