CAS-1466: Local truststore for proxy authentication

This pull fixes https://github.com/Jasig/cas/issues/472

## Description
CAS currently uses the JDK's default truststore to establish ssh handshakes specially for proxy calls. This can be improved by providing a CAS specific truststore, that would be empty by default. Untrusted proxies can be imported inside this particular store. Separating the store from Java's default always helps with platform upgrades that may cause prev changes to be overwritten.

Note that the default keystore would possibly be used in addition to the already available certs in Java. We simply just want to avoid polluting the default,and allow adopters to carry over their store, irrelevant of jdk version.

## Background
This is proposed under SEC_5:
https://wiki.jasig.org/display/CAS/Proposals+to+mitigate+security+risks

## How does it work?
CAS ships with an empty JKS keystore that is called `truststore.jks` whose password is `changeit` modeled after the default truststore. 

This truststore is loaded by a custom SSL socket factory that is able to realize self-signed certs as well as other imported authorities into the keystore:

```xml
<bean id="proxyTrustStoreSocketFactory"
          class="org.jasig.cas.authentication.TrustedProxyAuthenticationTrustStoreSslSocketFactory"
          c:trustStoreFile="${proxy.authn.truststore.file:classpath:truststore.jks}"
          c:trustStorePassword="${proxy.authn.truststore.psw:changeit}" />
```

Then, we have a special httpclient, that is backed by apache http-components, to use the factory above:

```xml
<bean id="trustStoreProxyHttpClient" parent="httpClient"
          c:sslSocketFactory-ref="proxyTrustStoreSocketFactory" />
```

## Why Apache Http Components?
We were making changes to HttpClient and @serac suggested that we should at some point consider taking advantage of the apache library. Provides a lot of other options and wraps the Java API quite well. It is a prominent and well looked-after library and sort of a standard tool in the Java realm.

The existing `SimpleHttpClient` that is backed by library now provides a lot of other integration hooks, for handling redirects, connection and proxy management as well as ability to authenticate an endpoint. All these  settings are optional, and the outer body of the API does not  change, only that some setters are deprecated. 
I think our strategy is to force mandatory parameters to be set through constructors and other parameters through setters.
I would go that way here and avoid these too many constructors...