(SERVER-39) Allow a certificate to be passed into a request via X header

This commit adds the ability for a certificate to be supplied in a web
request as the payload of a custom HTTP header, X-Client-Cert.  The
header will only be parsed for a value if the `allow-header-cert-info`
master setting is set to true.  When the certificate is retrieved, it
will be supplied as the client certificate to the Ruby request handler
stack, as a direct replacement for a certificate object that would be
typically be provided over SSL.
The way the logic works now is to honor the values passed in through the custom X- headers even if values are passed in via SSL.  So if you had passed in a value for X-Client-Cert and X-Client-DN but still had a certificate from the SSL exchange, the client cert passed down to the JRuby request handler would be the value from the X-Client-Cert header and the client DN passed to the JRuby request would be the value from the X-Client-DN.  Essentially, in this case, the value from the SSL certificate would ignored.  I didn't want to get into comparing DNs at this point, e.g., whether or not the one from the X-Client-DN matches the DN from the subject in the cert from the X-Client-Cert  and whether or not those may match the DN from the subject in the SSL client certificate.

I've struggled with what the right logic should be here.  I had been thinking that by enabling the "allow-header-cert-info" option that you're giving the client license to pass values for the custom headers which would be honored regardless of what may have been provided at the SSL layer -- and, therefore, you are taking responsibility for doing the real authentication of clients outside of the master.  I could certainly understand the argument for the reverse from a security perspective, though.