Refactor HTTPFutures

Summary:
There are a number of issues with HTTPFutures right now:

• There are three distinct, overlapping error code spaces (cURL, HTTP,

builtin) and error codes are a senseless mixture of meanlingless garbage, like
"2028" which means "curl error 28". And that's all you really get. This is
impossible to realistically figure out without asking me.

• The HTTPSFuture error implementation is just completely broken and can't

detect things HTTP status codes (e.g., 404) and gives a hopeless message for SSL
issues (see T96).

• In general, error messages are almost always unnecessarily confusing and

provide little useful information.

• There's no support for PUT and mixed support for raw data requests. We need

both in order to build on top of the Elastic Search HTTP API (see T355).

• HTTPSFuture doesn't return headers or status codes at all.
• There is no technical guarantee that HTTPFuture and HTTPSFuture provide the

same API.

• Code duplication between HTTP and HTTPS futures.

Here's how I've addressed these:

• The API futures conform to is now in a base class, and all the shared code

lives there.

• Errors are no longer raw codes; instead, they're objects which can

reasonably represent the several planes of error codes and provide meaningful
messages to the user.

• HTTPSFuture now handles response headers and status codes.
• Both futures now support PUT.

Test Plan:

• This is a relatively far-reaching change, but the only client of these

futures in any of the Phabricator stuff is ConduitClient which was trivial to
update for the API change.

• Built a test script (scripts/test/http.php) and used it to make a variety of

different types of requests to different sources.

• This diff is being submitted with the new code and it is possible it will

not break horribly.

Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran, amckinley
CC: aran, epriestley, jungejason
Differential Revision: 786