Add support for GCM mode (AES only).

The main change done by this commit is adding support
for MODE_GCM (NIST SP 800 38D). Test vectors are included.

The mode uses a C extension (Crypto.Util.galois._ghash)
to compute the GHASH step. The C implementation is the most
basic one and it is still significantly (5x times) slower than CTR.
Optimizations can be introduced using tables (CPU/memory trade-off)
or even AES NI instructions on newer x86 CPUs.

This patch also simplifies Crypto.Cipher.blockalgo.py by:
 * removing duplicated code previously shared by digest() and verify().
 * removing duplicated code previously shared by Crypto.Hash.CMAC
   and Crypto.Cipher.block_algo (management of internal buffers
   for MACs that can only operate on block aligned data, like
   CMAC, CBCMAC, and now also GHASH).
Add key setup speed benchmark for all AEAD modes.
Optimize GCM speed with pre-computed tables.

Tables take 64KByte per each key.

Encryption performance is more than doubled
(29 MBps vs 8MBps for AES128).

As a drawback, key setup is much slower (1300 key/s
on the same machine).
Optimize key setup for GCM mode.

GCM mode requires GHASH for 2 different operations: one for
the data (AD + ciphertext) and one for the IV.

Construction of tables to speed-up GHASH is very expensive
and it is worth doing only for the data, not for the IV.

This patch ensures that the GHASH for the IV does not
use tables, with a ~40% faster key setup.
Added get_mac_state() for GCM and EAX modes

This method is useful when one has to encrypt or decrypt multiple
messages:

- that all share the first part of the header, and that part is
  very large
- with the same key (but different IV)
- with GCM or EAX modes

An optimization consists in authenticating the first part of
the header only once, and then reuse the intermediate data
(that is, the MAC state) across all other messages.