Initial WasmThemis wrapper

[ilammy]

I'm getting better at writing JavaScript. Here's an initial version of WasmThemis wrapper. This is basic scaffolding that has

• project structure
• C API interfacing
• error handling
• automated testing
• packaging

which is good enough for start. It covers only key generation API, but adding other functions should be mostly mechanical job now. (Well, maybe except for Secure Session and its callbacks which are going to get tricky.)

---

• Add "wasm_themis" target for Makefile

The new wrapper was christened WasmThemis. Let's get rolling! It will live under src/wrappers/themis/wasm.

Introduce a new submakefile wasmthemis.mk which will contain all specific targets and configuration for building WasmThemis. The main target is wasm_themis, that's our user-facing target which should be used by developers. It will build the wrapper in BUILD_PATH.

We still don't have a proper wrapper so instead we're going to build libthemis.js library for now. This is our 'native code' as far as JavaScript is concerned. It simply links Themis static library and its dependencies with emcc. Note, however, a couple of caveats:

• Use EMSCRIPTEN_KEEPALIVE marker for public API

  Emscripten does dead-code elimination when linking final WebAssembly application. Anything not called from main() will be removed. And if there is no main() — typical for a library, eh? — then everything will be removed. We don't want that, so we use EMSCRIPTEN_KEEPALIVE to keep LLVM from optimizing out the functions we're going to use.

• Use EXTRA_EXPORTED_RUNTIME_METHODS to keep preamble.js API

  Emscripten provides a bunch of useful utilities for interacting with its sandbox from JavaScript. However, they are also optimized out by default. We need to explicitly list the APIs we're going to use.

Finally, all WebAssembly builds must be performed in properly configured Emscripten environment. That is, by calling emmake make wasm_themis. Add a simple check before running the build to ensure that the developer did not forget to use emmake.

• Initial "wasm-themis" npm package

We're going to publish WasmThemis via npm, create a package for that. Let's be nice and provide README and LICENSE files, fill in some informational fields in in package.json, etc. Note also these carefully crafted .gitignore and .npmignore files. They are meant to ensure that developers could do their thing in the working copy without accidentally committing unnecessary files to git or publishing them on npm.

The package is currently marked as private to prevent accidental publish. However, it is going to be named wasm-themis and that's the name used in README.

As for the wrapper code itself, let's start with secure key generation. This gives us a good start as we need to provide all the scaffolding around Node.js modules and Themis error handling. The interface stays similar to JsThemis, but there are no compatibility requirements. Thus we are able to provide strongly typed PrivateKey and PublicKey wrappers over Uint8Array, and expose then as read-only properties of KeyPair.

• Test harness for "wasm-themis" package

Add some test using Mocha as test runner (just like we do for JsThemis). We don't have much API to check, just verify some basic invariants.

Add test_wasm target to Makefile and integrate that into CI builds. Note that this target has to be run with emmake helper.

[ilammy]

Ready for review, please take a look.

[Lagovas]

lgtm