Add HMAC-based extract-and-expand key derivation function (HKDF)

HKDF (http://tools.ietf.org/html/rfc5869) is a key derivation algorithm.
As per the RFC:

   A key derivation function (KDF) is a basic and essential component of
   cryptographic systems.  Its goal is to take some source of initial
   keying material and derive from it one or more cryptographically
   strong secret keys.
   [...]
   HKDF follows the "extract-then-expand" paradigm, where the KDF
   logically consists of two modules.
   [...]
   The goal of the "extract" stage is to "concentrate" the possibly
   dispersed entropy of the input keying material into a short, but
   cryptographically strong, pseudorandom key.
   [...]
   The second stage "expands" the pseudorandom key to the desired
   length; the number and lengths of the output keys depend on the
   specific cryptographic algorithms for which the keys are needed.

Since HKDF is not covered by the GlobalPlatform Internal API specification
v1.0/v1.1, this commit introduces extensions to the specification.
More specifically: it defines new algorithms, a new object type and new
object attributes. This implementation supports all the usual hash
functions (MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) and may
produce output keys of length up to 4096 bits (currently limited only by
the maximum size allowed for an object of type TEE_TYPE_GENERIC_SECRET).
Aside from minor updates to object manipulation functions to support
the new data, the function TEE_DeriveKey() is mostly impacted.

The file documentation/crypto_hkdf.md contains the modifications to
the GP Internal API v1.0 spec in order to support HKDF.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Well, no, because it has nothing to do with the parameters coming from the TA. The pointers may be NULL only when the TEE is configured with some features disabled. Here, we would enter the error case if CFG_CRYPTO_{H,C,CBC_}MAC=n -- in other words, when all MAC algorithms are disabled at compile time.
Maybe TEE_ERROR_NOT_SUPPORTED would be more accurate, I'm not sure. But since we have similar crypto_ops tests returning TEE_ERROR_NOT_IMPLEMENTED (in tee_svc_cryp.c), I'd prefer to keep this as-is.