Feature Request: Add support for action post-processing (Delayed docker pause)

Currently, an activation is complete when a function returns a response (Or it's promise is fulfilled).

This architecture prevents doing any post-processing within the lifecycle of the action.
It would be great to be able to provide a response back to the action caller and be able to do some post processing before the activation is considered complete and the container is paused.

### Example use cases:

* An IoT device interacts with a function and needs a fast response. After the response is sent back to the device, the action needs to send data to an external data warehouse/Analytics system. We want to be able to send the response back to the device before sending the analytics data out. Currently this is possible only by creating two separate actions which means using two containers instead of one.

* Integration with Microsoft Bot Framework (https://dev.botframework.com/). The bot framework decouples bot message receive from reply. When the bot message is received, the framework needs to send an immediate acknowledgement to the chatbot and then do some post processing before sending one or more replies through the Microsoft bot backend.

Trying to integrate the bot framework with the current architecture fails because the docker is paused before the post processing is complete.

### Possible solutions:

Allow an action to declare when it's considered complete, the options could be:
1. When function returns (default)
2. When Node JS event loop is empty (Or the equivalent for other programming languages)
3. Using a specific hook (Which could be made available through https://github.com/apache/incubator-openwhisk-client-js and other clients) which will single back to Openwhisk that the action is complete.

The issue does not identify specific files, tests, or entry points. Start by mapping where activation completion triggers container pausing, then evaluate the proposed completion mechanisms and their effects across runtimes. Done would require an agreed design, implementation, and coverage for the selected lifecycle behavior.

Written by the indexing model from the issue text.