[JENKINS-21401] Add support for NTLM authentication, such as TFS 2013 Git servers

Overview
======
Microsoft's Team Foundation Server 2013 supports a Git server hosted on IIS, usually configured with "Windows authentication" for a single-sign on experience in an organization's intranet.  Unfortunately, that makes it slightly non-standard as a Git server, hence [JENKINS-20401](https://issues.jenkins-ci.org/browse/JENKINS-21401).

This pull request adds support for [optional] NTLM authentication, making the Jenkins Git-Client plugin "just work" with TFS 2013 Git servers.  To make this happen, I had to upgrade to Apache HttpComponents (from the unsupported Apache Commons HttpClient 3.x) and also switch to the new classes (i.e. `org.apache.http.*`).

Manual Testing
==========
There is a small element of risk involved since the new HttpComponents API didn't map 1-to-1 with the old one, so I performed more testing as a result.  I deployed the `git-client.hpi` I built into a test Jenkins instance (running on Windows Server), which has one Linux (CentOS 6.2) agent.
 1. Created a job with a Git repository using TFS 2013 Git (with a server we have on our LAN) and confirmed that:
    * 1.1 Providing Credentials in the configuration page got the "Failed to connect ... (status = 401)" error message to go away.
    * 1.2 The job was able to clone and fetch when running on the (Windows) master.
    * 1.3 The job was able to clone and fetch when running on the (Linux) slave.
    * 1.4 The job was able to poll.
 2. Created a job with a Git repository using a Git server that did not require authentication (GitHub) and repeated tests 1.2, 1.3 and 1.4.
 3. Created a job with a Git repository using a Git server through a proxy that did not require authentication (I used Squid 3.1) and repeated tests 1.2, 1.3 and 1.4.
 4. Created a job with a Git repository using a Git server through a proxy that required authentication (Squid 3.1 with Basic auth) and repeated tests 1.2, 1.3 and 1.4.
 5. Created a job with a Git repository using a Git server that used a self-signed certificate with `org.jenkinsci.plugins.gitclient.GitClient.untrustedSSL` undefined (defaults to `false`) and repeated tests 1.2, 1.3 and 1.4.  1.2 and 1.3 would fail, as expected, with "sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target" while 1.4 always reported a change, which triggered a build on every check (not sure if this is the right behaviour, but I didn't touch that part of the code, so presumably it worked like that before).
 6. Created a job with a Git repository using a Git server that used a self-signed certificate with `org.jenkinsci.plugins.gitclient.GitClient.untrustedSSL` set to `true` and repeated tests 1.2, 1.3 and 1.4.
    * 6.1 Test 1.2 was able to check the credentials against the remote (since that part is using Apache HttpComponents) but would fail the build when it called `git fetch (...)` because git.exe performs its own certificate check.
    * 6.2 Test 1.3 failed until I also added `-Dorg.jenkinsci.plugins.gitclient.GitClient.untrustedSSL=true` in the node's "JVM Options", then reconnected the slave, because it appears the `CliGitAPIImpl` code executes directly on the slave's JVM.  After doing all that, I got the same behaviour as 6.1: `git fetch` failed due to an invalid certificate.
    * 6.3 Test 1.4 reported a change, probably because none of the builds were able to fetch a repo to have a changeset to compare with.