Add support for httprequestoptions in salesforce request

[mtuchi]

Description
In jsforce v3, connection.request() takes are two request arguments. HttpRequest and HttpRequestOptions. In #1070 we only support HttpRequest option. We should also add support for HttpRequestOptions and expose these options in http.request(path, request, options)

[josephjclark]

So jsforce is like connection.request(req, options).

At the moment we only allow the req properites to be set. We don't expose these directly - we expose our own options and map them this request object.

What you're saying is that we also want to expose the options object here, which looks like this:

HttpRequestOptions: {
    encoding?: BufferEncoding;
    followRedirect?: boolean | ((redirectUrl) => [HttpRequest](https://jsforce.github.io/jsforce/types/types_common.HttpRequest.html) | null);
    httpProxy?: string;
    retry?: {
        errorCodes?: string[];
        maxRetries?: number;
        methods?: [HttpMethods](https://jsforce.github.io/jsforce/types/types_common.HttpMethods.html)[];
        minTimeout?: number;
        statusCodes?: number[];
        timeoutFactor?: number;
    };
    timeout?: number;
}

I'm not really so sure. We should expose the same sorts of options like http does, like timeout. But for most of these options I think we should just provide sensible defaults.

The fact that we use connection.requesdt under-the-hood is a detail. We shouldn't expose it directly to users.

If users want to use the connection directly, we should explore sharing the client as a separate issue. For google sheets we've explored passing the sheets client straight to fn(), like this:

fn((state, sheets) =>{ 
//    .. do stuff with sheets
});

This would be strictly for advanced users only. In the case of sheets, we think the client object leaks credentials so we're not really comfortable doing it.