Historically, WasmThemis has exported only the "initialized" promise.
WasmThemis was not modularized and kicked off "libthemis.wasm" download
right after the module is loaded. Moreover, there was no way to use
a different path to WebAssembly code: it had to be located in a file
named "libthemis.wasm" next to the JavaScript code bundle.

TypeScript rewrite introduced an alternative interface "initialize()"
which allows to specify the URL. However, this required WasmThemis
modularization. That is, WasmThemis *will not* be initialized unless
initialize() is called.

This introduces two issues with backwards compatibility:

  1. "initialize" promise was gone.

  2. You can no longer expect that WasmThemis will be downloaded
     in background without awaiting any promise.

Due to modularization, there is no (practical) way to fix the second
issue. Just don't do, it's a bad practice.

However, absence of "initialized" is a real breaking change that will
break well-formed applications.

Reintroduce the "initialized" promise and make sure it works by calling
the "initialize()" function behind the scenes. It's a bit of a hack, but
it works, so whatever.

Note that "initialize" is *not* deprecated or anything. It's a perfectly
valid API if you don't need to specify a custom path to "libthemis.wasm"

Revert previous changes that made all examples and tests use
"initialize()" due to absence of "initialized". Now that it's there,
let's use the old thing. (And this also ensures that it exists and
working.)

Add a bunch of tests to verify initialization specifically. Each of
these has to be a separate file, separately tested by an individual
mocha process (becaue you can only initialize WasmThemis once).

The "invalid path" test prints out some errors to stderr. This is
default behavior for Emscripten shim. It can be overriden with more
parameters to libthemisFn(), but I'm not ready to introduce too much
customizability to it yet.

We're going through with this API, so let's tell the users that it's
available now.