Refactor Dataflow LCO to work with futures

[sithhell]

The dataflow LCO currently doesn't integrate very well with the rest of hpx futures. In order to efficiently use the dataflow LCO it needs to be rewritten in terms hpx::future. That means:

1. Arguments are futures, not dataflow_base
2. dataflow_base needs to completely vanish

During this refactoring #319 should be covered.

[hkaiser]

The new local::dataflow goes a first step into this direction

[sithhell]

I think we can close this, once hpx::lcos::dataflow is removed. I believe the general consensus is that is superfluous and gets superseded by hpx::lcos::local::dataflow. Having two dataflow APIs is confusing.

[hkaiser]

I agree mostly. The only thing the dataflow component has which the local dataflow has not is to be able to distribute the execution flow of the dataflow itself over several localities.

[sithhell]

That is certainly true. However, I'd argue that distributing control flow from a single master (as more or less advertised by the dataflow component) is not going to scale, as shown by experiments in the past. A scalable distribution of the data flow is however perfectly possible with the local dataflow, as demonstrated by, for example the mini ghost example.

[hkaiser]

Ok, let's remove the dataflow component. However, I'd like to re-implement the existing dataflow performance counters. That could be another ticket, though.

[hkaiser]

The only performance counter which seems to be useful in the context of the new dataflow() function would be to count how often it was invoked. If we create this performance counter we probably want to implement similar counters for other API functions as well. For this reason I'd say, let's go ahead with removing the dataflow component now and open a separate ticket for creating performance counters exposing the number of invocations for various API functions.