Add more checks to the encryption/decryption logic

[StephanvanSchaik]

This PR adds a few more commits to harden the encryption/decryption logic in lopdf a bit more against invalid inputs.

The first commit ensures that the file encryption length is always 128 bits. It basically sets the Length file to 128 bits and removes the explicit length field in EncryptionVersion::V4.

The second commit adds checks to the AES crypt filters to ensure that the key length is 16 bytes for 128-bit AES and 32 bytes for 256-bit AES and returns errors (instead of potentially causing a panic).

The third commit removes .unwrap() in the AES crypt filters when invalid padding is encountered. This can happen during decryption when the file encryption key is simply not the actual file encryption key that was used to encrypt the streams (e.g., in PDF 2.0 it is possible to store a file encryption key different from the one used to encrypt the streams). This fixes #398. I have also replaced .unwrap() when encrypting which can also theoretically result in padding errors, but shouldn't practically occur (but it just better to return an error rather than causing a panic).