Support for invocations based on websocket messages

Provide a mechanism by which API invocations (e.g. to a Whisk action) may be triggered by a message to a websocket.

The basic approach could be something like:
- Client attempts to make a websocket connection to the API gateway on a path (e.g. /tenant/basepath/api)
- Gateway enforces pre-request policies (e.g. client id/secret, oauth, rate limit, etc).
- Assuming pre-request checks succeed, gateway allows a websocket upgrade and accepts the connection
- When the client sends a message, the gateway will invoke the target endpoint defined in the API doc, passing the message in the request body. If security policies were run as part of the initial connection, then any API key or user identity information would be included in the headers to the backend endpoint.
- Once the backend request is complete, the gateway will pass any response body to the client via a websocket message.

There may also be a case where the API developer may wish the gateway to proxy the entire websocket connection through to the backend. This could be detected via the proxy policy having a `ws://` or `wss://` protocol in the target URL. Some work would still need to be done there to define how that works, but that would enable push messages from a backend. This is a more advanced use-case that probably needs addition design.

The issue names no files, tests, or implementation entry points. Start by mapping the API gateway's connection handling and action-invocation paths, then review how existing policies and proxy targets are represented. Done would require an agreed design and tests covering websocket upgrades, message-triggered invocations, responses, and any backend websocket proxying.

Written by the indexing model from the issue text.