Feature/Improvement: pick LoadBalancer Strategy based on annotation

When working on the new mechanism of processing of the activations we haven't found a better extension point on where it could be plugged into the system other than changing the logic of Load Balancer.

We don't want to introduce backward incompatibilities of any kind, so this approach must work alongside the default one. This motivates us to introduce a mechanism that would allow selecting the Load Balancers based on some characteristics of activations. We considered `kind` as one possibility for such characteristic, and it could be added later. For now, `annotation` looks like the most straightforward way (with fewer drawbacks)

What we propose is to introduce is a new load balancer called MuxBalancer. When action is created, a developer can specify "activationStrategy" annotation. If OpenWhisk is configured to use MuxBalancer, it will pick up the annotation value and will look in the map of the configured activation strategies for that alias. In case if the alias is found, it will delegate the publishing of the activation to the LoadBalancer corresponding to the alias. Otherwise, MuxBalancer will use the "default" Load Balancer to delegate the publication.

The configuration of the MuxBalancer looks like folloving:
```
whisk.loadbalancer {
strategy {
default = "fully.qualified.class.name.for. LoadBalancer0"
custom = {
"activationStrategyName1" = "fully.qualified.class.name.for. LoadBalancer1"
"activationStrategyName2" = "fully.qualified.class.name.for. LoadBalancer2"
...
}
}
}
```
A developer would use it in the following way:
`wsk action create hello hello.js --annotation activationStrategy activationStrategyName1`

Potentially we could add the possibility to restrict kinds on which load balancer would apply, etc

Start by tracing the existing LoadBalancer strategy configuration and activation publication path; the issue proposes adding a MuxBalancer. Review how the activationStrategy annotation from `wsk action create` is exposed, then define how aliases select configured strategies and how unknown aliases fall back to the default. Done means the configuration and delegation behavior work without breaking the default strategy.

Written by the indexing model from the issue text.