Add ability to obtain authenticated user info from HTTP headers to tk-authz

This ticket is basically about adding the ability to support the "external SSL termination" use case from Puppet Server to the trapperkeeper-authorization - http://docs.puppetlabs.com/puppetserver/2.1/external_ssl_termination.html. Specifically, this would add the ability for the authenticated user of the request to be pulled from X-Client-* headers as opposed to only via the SSL client certificate, controlled via an allow-header-cert-info setting.

Following Puppet Server's lead, the implementation for trapperkeeper-authorization would consist of the following:

1) Add an allow-header-cert-info setting to the authorization config section.

For a value of false (the default), authenticated user info will be derived only from an SSL client certificate. For a value of true, authenticated user info will be derived from evaluating content in the X-Client HTTP headers.

2) For the allow-header-cert-info true case:

a) Extract the authenticated user's name from the Common Name (CN) in the X-Client-DN, if possible. Associate the resulting name with the authorization.name key on the Ring request.

b) If the authenticated user's name could be found from within the X-Client-DN header and if the X-Client-Verify header is present and set to a value of "SUCCESS", associate a value of true with the authorization.authentic? key on the Ring request.

c) Attempt to URL decode and extract a Base-64 PEM encoded form of the client certificate from the X-Client-Cert header and convert the result into a java.security.cert.X509Certificate and attach the resulting object to the authorization.client-cert key. (This part isn't relevant to the identity that tk-authz uses when authorizing a request but is necessary in order to flow through the client certificate to downstream consumers of the Ring request map, as Puppet Server does today.)

With current code in place in trapperkeeper-authorization, the existing logic in tk-authz should be able to authorize the user via an identity deriving from HTTP X-Client headers.

This work will enable work to be done in SERVER-763 to infer the authenticated user's identity from the authorization key in the Ring request map when provided by trapperkeeper-authorization.