Extend tool calling API to also support HTTP POST

[proycon]

If I understand things correctly, currently the tool calling API always does a HTTP get passing a URL that the remote service should download. This is a good solution but not all services will support this, some may require a POST (or PUT) request with the actual data in the content body.

An example is FLAT (clarin-eric/switchboard-tool-registry#7), which current expects a specifically formatted POST request. Now since this is my own tool I could of course add a switchboard-compliant endpoint with relative ease, but that's won't always be the case with all services, and I wonder to what extent the switchboard tool calling API itself shouldn't become more flexible, rather than putting this burden on the tools to be called. More flexibility would lead to easier incorporation of more tools.

[emanueldima]

I think that allowing for some flexibility is a good idea, so we should keep this in mind. Other things to keep in mind: 1. Using POST may not work with services that require Shibboleth authentication. 2. If the client sends the data to the service directly (by POST), this means more data traffic on mobile connections.

To be considered in #4