augment! and augmentbatch!

[Evizero]

This allows to augment a full batch at once and store the result into a single higher-dim array (e.g. HxWxN). It also allows for multithreaded use where the images of a batch are processed in parallel. To be able to do that safely I introduced a Mutex to protect access to the global RNG.

[Evizero]

@timholy I saw in ImageFiltering.jl that you follow a convention of specifying the ComputationalResources.AbstractResource as the first argument, even for mutating functions (example https://github.com/JuliaImages/ImageFiltering.jl/blob/master/src/imfilter.jl#L117). For consistency I also adopted this convention.

I do wonder though, is there a specific reasoning behind this "overshadowing" of the typical convention of specifying the output variable first?

[timholy]

It's been a while since I thought that through. If I had a great reason, I can't reconstruct it now. For what it's worth, here are my thoughts:

• it's kind of in a separate category, and having it compete for space/order with other optional arguments more specific to the particular function seemed fraught. (Check out the dispatch hierarchy in imfilter.jl, which is pretty hairy and took a long time to get right.)

• it seems a little bit like the convention of putting the function as the first argument with do-block syntax (you're "running it on the resource")

The last is pretty weak. The first might have a bit more merit?

[Evizero]

I think both arguments make sense. Thanks for explaining.

as a side note on the first argument: Using the first position is certainly "safer" than last position. I have had problems before by having such optional arguments as the last positional parameter since it basically removed the option to use Vararg sensibly