https://www.openssl.org/docs/crypto/EVP_aes_256_cbc.html

EVP_DecryptInit_ex(), EVP_DecryptUpdate() and EVP_DecryptFinal_ex() are the corresponding decryption operations. EVP_DecryptFinal() will return an error code if padding is enabled and the final block is not correctly formatted. The parameters and restrictions are identical to the encryption operations except that if padding is enabled the decrypted data buffer out passed to EVP_DecryptUpdate() should have sufficient room for (inl + cipher_block_size) bytes unless the cipher block size is 1 in which case inl bytes is sufficient.

I doubt this is correct, but let's rather be defensive here.

This has special and extremely fast HW acceleration on e.g recent Intel CPUs: AES-NI and PCLMULQDQ.

Notes:

a) I had to kill AES.iv method, it just did not work for aes-gcm as done by openssl.
As the incremented IV (counter) can't be read back, we have to keep and manually increment it in Key.enc_iv.

b) there is a hack in AES.compute_tag_and_encrypt to add 16B of zero to the right of the gmac (which is also 16B)
because the current callers expects 32B. AES.check_tag_and_encrypt is tolerant of such a 32B tag, but will only
use the left 16B and ignore the right 16B if needed. this is a bit dirty, but I didn't want to change the header layout
within this changeset.

c) switched from mac&encrypt to encrypt-then-mac (using aes-gcm) for the keyfile 'data' entry

d) also added a test that creates the testdata needed for the constants at top of testsuite/key.py

e) I kept enc_hmac_key although it is not used by the code in this changeset. But we'll need to
keep supporting the old algorithms, too.