Validate the configuration in the constructor, reject malformed encrypted data early

What's Changed

• Follow-ups to the constructor validation from 2.3.0 (#35). A numeric key id no longer fails with a TypeError, and InvalidKeyPrefixException no longer includes the key value in its message. A key with no prefix at all now throws the new MissingKeyPrefixException, which extends InvalidKeyPrefixException, so existing catch blocks keep working.

2.3.1 release notes below

• Require ext-sodium in composer.json (#34). The requirement was already announced in the 2.3.0 release notes below, but composer.json in 2.3.0 was accidentally missing it, this release adds it.

2.3.0 release notes below

• Validate keys, key ids, and the active key id in the constructor instead of failing at first use (#31)
  • A misconfigured key - wrong length, not valid hex, a key id that would break the output format (empty or containing $), or an active key id missing from the keys array - now throws when the service is created, not on the first encrypt() call after a deploy.
  • New exceptions: InvalidKeyEncodingException, InvalidKeyLengthException, InvalidKeyIdException, ActiveKeyIdNotFoundException.
• Reject encrypted data in a format that this library never produces (#32)
  • Inputs like garbage$keyId$ciphertext, $keyId$ or $$ciphertext now throw the new InvalidCipherTextFormatException instead of failing later with confusing downstream exceptions.
  • InvalidNumberOfComponentsException now extends the new class, so existing catch blocks keep working.
• Documentation additions (#33)
  • Keys defined in Nette config parameters also end up in the compiled DI container file in the temp directory, treat it accordingly.
  • From the README: "The key id in the output […] is the only part of the output not protected against tampering […] Never configure the same key under two different ids."

Upgrade notes

• Nothing changes for correctly configured setups, and everything they ever encrypted still decrypts.
• The library now requires ext-sodium (bundled with PHP since 7.2); previously it could in theory run on the sodium_compat polyfill that Halite uses.
• If a configuration was broken without you knowing, the constructor will now tell you.
• One case possibly needs care: a key truncated to an odd number of hex characters (e.g. 63 instead of 64) used to work, because the decoder used previously, Hex::decode(), would quietly prepend a 0 instead of rejecting the input, so the key was used as if it had a leading zero, without anyone knowing. Keys are now decoded with sodium_hex2bin(), which rejects anything that is not valid hex, so such a configuration throws InvalidKeyEncodingException. To keep the already encrypted data readable, add the 0 back yourself, right after the prefix separator - that is byte for byte the key that was actually used.