GitLab

 - no encryption for now
 - no support in belenios-tool.html

It was redundant with ELECTION_DATA.

This field was most of the time set to None. The only non-None usage was
not really needed.

Add module Platform: single interface to functions that depend on the
runtime. For now, the native (existing one), and a dummy one that
constitutes a skeleton for the js one.

All calls to Cryptokit, Z, Calendar (which depends on Unix) in the
command-line tool now go through this module.

SITE.register_election takes only parsed stuff.

Move code specific to a group implementation there, and use it
everywhere else.

They do not behave as expected on serialized JSON objects. Instead,
directly export a reader and a writer as needed.

In each directory, always open in the following order:
 1. third-party libraries
 2. serializable
 3. signatures
 4. common

Also, always open modules from lib/* before. This order is reflected
in *.mllib files.

Additionally, open more frequently serialization modules.

 - metadata is specific to web, move it there
 - create Web_serializable, and also move randomness there
 - metadata is not optional (but its components can be)
 - rename user_type into user_domain
 - serializable version of ACLs

It is used for ballots as well as records...

A record (i.e. who voted, when and with which credential in the
context of the web server) is a notion that does not exist in the
cryptographic protocol and does not really make sense in the context
of the command-line tool.

By the way, we add the notion of receipt which, in the context of the
web server, is the ballot hash computed by the server.

Bonus: when a ballot is accepted, we compute its hash only once.

The credential is taken from the file given to --privkey (if any).

 * drop ELECTION_PARAMS signature
 * parameters are no longer implicit in ELECTION signature
 * redesign WEB_ELECTION signature

Side-effect: public_key is not used during an election. We make it
lazy for now.