Add symmetric operations to the proposal and implementation

[jedisct1]

This adds symmetric operations to the signatures proposal, based on the ideas from #19.

The example implementation was updated accordingly, and a couple algorithms are available in order to experiment with the API.

Sharing the same functions for all symmetric operations seems to work pretty nicely.

The WITX file has been greatly improved and includes some example patterns for common symmetric operations.

New types and error codes to support the new functions have been added.

In the signature proposal, quite a lot of handles were sometimes required because everything had to be tied to a root context.

For example, creating a key used to require a bunch of objects:

signature_op = signature_op_open(algorithm)?
keypair_builder = signature_keypair_builder_open(signature_op)?
keypair = signature_keypair_generate(keypair_builder)?;

Applying the same pattern for symmetric operations made common operations a little bit tedious.

The justification for having many handles was to make it possible to set options on handles.

However, only a few functions may really need options, so they can be passed directly to these, greatly simplifying the API.

This is what has been done for symmetric functions, and the simplification has been backported to the signature functions.

A wasmtime fork with support for that API is also available for testing purposes (especially: evaluate what it would take to writing bindings on top of it).

[jedisct1]

Thanks a ton for your feedback!

Commenting on a PR is not convenient, so let's merge this in order to make things easier to review, test and comment.

In order to actually use the API, which is probably the best way to get an idea of how it feels to write bindings for it, there is a wasmtime branch that exposes it. I will probably add a wasm3 integration as well, as wasm3 is really nice for quick experimentation.

There are also preliminary AssemblyScript bindings.

AssemblyScript is an interesting target, because unlike Rust, the types exposed by witx interfaces don't map to its native types well. There are no pointers (only unchecked casts between arbitrary types as a workaround), there is no stack, strings are UTF-16, there are no unions, no options...

Writing bindings for the core WASI module required a lot of manual work and was quite tricky, so I was expecting things to be worse with the crypto module.

It turned out not to be the case at all. The bindings are ridiculously small and simple compared to the core WASI module. Not using complicated or C-like data structures and having only one kind of union really helped.