Single future.control argument rather than multiple, individual future.* arguments

@mllg [wrote](https://github.com/HenrikBengtsson/future.apply/issues/25#issuecomment-420955847):

> Have you considered to introduce a control object (in the fashion of passing a `rpart.control`-object to `rpart()`)? A `future.control`-object could bundle all arguments. Would be good for the overview (also in the documentation) and ...

Yes, I've been having internal (as in lots of inner voices ;)) debates about this and it's been discussed with other in the past. I'm not opposed to it. The main reason I've stayed away from it is that we have to deside exactly how the control elements should be controlled.

> ... you would avoid inconsistencies like https://github.com/HenrikBengtsson/future.apply/issues/26.

You're meaning in the sense that the future.apply package and other similar high-level packages (e.g. furrr) won't have to know about future-specific arguments and can just pass whatever down to the future package? That's a nice side effect I haven't thought of before.

However, not all elements in `future.control` should be passed down to the future package. For instance, `scheduling` and `chunk.size` are higher level properties. If so, do they belong to a `future.control` argument or should they be separate?

So several things to think of. Thanks for bringing this up.