Completion of implementation: valexp predicates

[vanrein]

The various predicates are not completely implemented in starttls.c yet, and should be. These are the missing pieces:

• L and l should be related to cryptographic security strength levels, which ought to be defined in an invariant formulation
• I and i are currently dangerously insecure -- they check the remote identity but forego the comparison to the remote identity
• A relies on cmd->valflag which is not currently set yet
• D and d are untested, and founded on badly documented GnuTLS logic; perhaps rephrase in online.c functionality, and dispatch of the extra GnuTLS library with DANE support
• R and r should get hold of revocation information
• E and e should lookup Extended Key Usage OIDs, depending on the service at hand
• P and p should be implemented by looking into trust.db (and possibly adding a value)
• U and u are not implemented (but actually documented as part of I and i, double attention?)

Note that the rest is working quite nicely -- T and t for instance, as well as I and i as a check for presence of an identity (and only that) and G and g for various global directory patterns, and O and o for various online verifications, and C, c, S, s to check for roles, and F for demanding forward secrecy. On top of that, the logic works very well and the integration within starttls_thread() seems to be quite alright. We have effectively replaced the gnutls_verify() functionality, which is a big step towards the flexible and configurable validation expressions that we aspire for the TLS Pool.

[vanrein]

Added for #85 (Prepare for Quantum Computing):

• Q and q require the connection to be proofed against Quantum Computing; q refers to authentication and Q refers to encryption of the application level; there is currently no flag to protect the names exchanged during the handshake, but we may expand the definition of Q to that end when it becomes practical in the future.