Config option to return 502 on blocking activation timeout

Since beginning to use OpenWhisk, we regularly have questions regarding blocking activations and the 60s (now configurable) timeout, where the activation submitted as "blocking" turns into "nonblocking".

I think it would be generally useful to allow the system to treat this as an error, as opposed to returning a 202 with the activation still in progress.
Basic reasons are:
* Customers are confused by not having a consistent response related to the action config - e.g. setting a timeout greater than 60s (or whatever the configured blocking timeout is) would typically imply an error if duration exceeds 60s, but currently it results in 202, with activation completing "sometime later".
* We don't have any customers that actually leverage this ability, because building a client that handles 200+response as well as 202+polling is complicated.

What I suggest is:
* add a config option like `downgrade-blocking-activation=true`
* if true, keep existing behavior
* if false, return a 502 when `max-wait-for-blocking-activation` is exceeded, same as exceeding the action-configured timeout
* in the case of blocking timeout, indicate the action exceeded the blocking timeout, as opposed to the action timeout, e.g. `The action exceeded the blocking activation time limit of 60000 milliseconds.`
* due to no coordination between activation handling at controller and invoker: when timeout is past for a blocking activation, don't schedule the activation at all (since no one will ever look for the result).
* in case of "not scheduling the activation", it *might* be useful to let users know whether the timeout occured before processing the action, or during (e.g. was wait time too high, or init time/duration?). To do this, we can proceed with creating the activation at the invoker with a timeout error indicating "wait time too high" or "execution too long". I'm not sure creating these failure activation records is actually that useful so it might should be a separate config as well, like `create-blocking-timeout-activations`

No files, tests, or concrete entry points are named. Start by reviewing the controller and invoker handling of blocking activations, including max-wait-for-blocking-activation and the existing downgrade behavior. Done requires an agreed configuration, timeout response semantics, scheduling behavior, and coverage for the selected cases.

Written by the indexing model from the issue text.