Consistent handling of armor max size

[covert-encryption]

The setting covert.cli.ARMOR_MAX_SIZE should refer to binary size, perhaps with some headroom when reading armored input instead. The current implementation does not make that distinction and needs to be fixed because it may reject something successfully armored as too large to be armored.

Additionally, this should be refactored into covert.util or another more appropriate module because it is not only relevant to CLI.

[covert-encryption]

The text form armored data is about 34 % larger than the equivalent binary. However, we can accept it to be up to 2 * ARMOR_MAX_SIZE, to keep things simple and to avoid introducing another variable for a more precisely calculated matching size.

Thus,

1. Move ARMOR_MAX_SIZE to covert.util, and be sure that cli and gui both import it from there.
2. Make sure that the size limit is two times that value in decryption code (cli and gui) where the input is armored text (so that anything successfully encrypted with armoring is not rejected on decryption).

Encryption still uses ARMOR_MAX_SIZE as is, as the limit for maximum binary size, possibly applied to a.total_size which then also is smaller than the final encrypted binary produced.