Usability Improvements to sys.Http

## 1) Change onError to actually return the HTTP error

Currently onError() only sends application-specific semantic errors (e.g. "Http status: #400" which is hardcoded as a thrown exception). This eats all error information sent by the client explaining the error. For example, the server might return "missing parameter" information with their 400 response, but there is no way to access that information from sys.Http because the class only returns its own errors.

I believe that the following small change would fix the issue:

```haxe

//in sys.Http

public override function request(?post:Bool) {
var output = new haxe.io.BytesOutput();
var old = onError;
var err = false;
onError = function(e) {
responseBytes = output.getBytes();
err = true;
onError = old;
onError(e); //TODO: change this to something like onError(responseBytes.toString()); or onError(e + " : " + responseBytes.toString());
}
post = post || postBytes != null || postData != null;
customRequest(post, output);
if (!err) {
success(output.getBytes());
}
}

```

## 2) Increase default cnxTimeout AND/OR give Sockets better error message on timeout

Current default timeout for Sockets is 10 seconds which is actually extremely likely to be hit for many applications. Sure, this is directly configurable, but a) I don't see any reason why the default timeout should be this short length and b) if the socket does time out the http.request() just throws a meaningless "Blocked" error which doesn't actually indicate that there was a timeout or tell the user that they need to increase cnxTimeout.

Start by reading sys.Http.request and its customRequest/onError flow, then inspect Socket handling of cnxTimeout and the "Blocked" error. The work is complete when HTTP error responses preserve the server’s error information and socket timeouts produce a meaningful diagnostic or appropriate default behavior.

Written by the indexing model from the issue text.