Version 0.4.0

This release mainly adds support for multiple token recipients, deals with the newly released RFCs,
and fixes no_std support.
Note that the cipher interfaces have been refactored in a major way.

Added

• The CoapOscore profile has been added as an AceProfile.
• Support for multiple token recipients has been added. Specifically, the following new methods have been added:
  • encrypt_access_token_multiple / decrypt_access_token_multiple: Creates a new access token encoded as a
    CoseEncrypt rather than a CoseEncrypt0. The user passes in a vector of keys on encryption, these will then be
    used as Key Encryption Keys. The Content Encryption Key is generated by the MultipleEncryptCipher required by
    the function. On decryption, the correct recipient structure will be identified by the key ID of the passed-in key.
  • sign_access_token_multiple / decrypt_access_token_multiple: Creates a new access token encoded as a CoseSign
    rather than a CoseSign1. The user passes in a vector of keys when signing, and a recipient will be created
    for each key. When verifying, the correct recipient structure will be identified by the key ID of the passed-in key.

Changed

• The ciphers' API has been majorly changed. As a result, the API for the token functions has changed as well.
  Users no longer need to pass in an instance of the cipher, they only need to specify the type parameter, as the
  cipher's methods no longer need self as a parameter. Additionally, users now need to pass in the key for the
  corresponding operation, specified as a CoseKey. For more information, read the
  documentation of CoseEncryptCipher, CoseSignCipher, or CoseMacCipher, as well as of the token functions.
• The documentation has been updated to refer to the recently released RFCs instead of the now outdated internet drafts.

Fixed

• The crate now properly compiles in no_std environments, and no tests are failing. This fixes #2.
  (Contributed by @JKRhb in #3.)

---

Full Changelog: v0.3.1...v0.4.0