feat #22: New invoke syntax proposal

[vejja]

What kind of change does this PR introduce?

Closes #22

What is the current behavior?

The invoke() function currently implements the following behavior:

• The input parameter must be provided in a way that is compatible with the low-level fetch() function. This obliges the user to write significant amounts of boilerplate code (e.g. to JSON.parse() the body or set the right headers), as described in issue Calling invoke via Android OS without specifying content-type header results in a failed request #14
• The output is a { data, error } object where data has already been automagically de-serialized. However the richer underlying Response object from the fetch() call is lost (e.g. status code, headers, etc.), as described in issue shouldThrowOnError does not apply to functions.invoke() #20

What is the new behavior?

The new behavior modifies the prototype of invoke() in accordance with the proposal set out under feature request #22 :

• The input parameter can be provided as an object. The invoke function automagically serializes the body and sets the headers. This reduces the amount of boilerplate for the most common input data types
• The output is still de-serialized automagically. However the richer underlying Response object can now be accessed via a third options parameter, which provides callback entry points to the fetch() call.

Please refer to the accompanying README.md file for further details on the new proposed behavior of invoke.

Additional context

This PR closes #22.
It also fixes #20 and fixes #14.

Notes:

1. This PR is a draft which is intended to be reviewed as a skeleton-basis only for comments and feedbacks.
2. This PR makes extensive use of the standard Fetch, Request, and Response Web APIs. Previous options that used to be passed as named parameters are now passed according to the prototypes of these APIs.
3. The outgoing request headers are written according to the data type on the way out, and the incoming data type is inferred from reading the response headers on the way back. This is an opinionated convention which I believe covers 99.9% of the use cases of a serverless fetch() functionality.

[inian]

Hey @vejja, thank you for the PR ❤️ We couldn't merge this in directly since this would be a breaking change and was a lot going on here. To break it down, the PR proposes these changes

automatically adding content types to request
automatically parsing objects as json by default
returning an error if function throws an error
All these have been added to our next branch. We will release this in our next breaking version of the library.

request and response transformers
I am not sure if I like this pattern, it mixes callbacks and promises for the user. It also blocks certain transformations (method, etc) which is more things for the developer to remember. It is easier to just add more optional arguments to invokeOptions and let the user transform before or after the function call.