ParallelFor with BoxND

[AlexanderSinn]

Summary

This PR adds the ability to use ParallelFor(RNG) and Loop(OnCpu) variants with BoxND.

Additional background

The functions supplied to ParallelFor etc. can have one of the following input parameter combinations when used with BoxND<dim>:

(int, int, ...) // dim times
(IntVectND<dim>)
(int, int, int) // if dim is 1 or 2, for backwards compatability

After that come additional parameters such as int n, Gpu::KernelInfo or RandomEngine.

I had to mark the constructor of GPU Handler as explicit to avoid ambiguity between (i, j, 0) and (i, j, Gpu::Handler).

Checklist

The proposed changes:

• fix a bug or incorrect behavior in AMReX
• add new capabilities to AMReX
• changes answers in the test suite to more than roundoff level
• are likely to significantly affect the results of downstream AMReX users
• include documentation in the code and/or rst files, if appropriate

[WeiqunZhang]

I am a little bit worried by loops like this

        for (int i2 = lo[2], h2 = hi[2]; i2 <= h2; ++i2) { iv[2] = i2;
        for (int i1 = lo[1], h1 = hi[1]; i1 <= h1; ++i1) { iv[1] = i1;
        for (int i0 = lo[0], h0 = hi[0]; i0 <= h0; ++i0) { iv[0] = i0;
            call_f_intvect(f,iv);
        }}}

where iv is IntVectND<dim>. The compilers I have tried seem to have figured out that iv[0] = i0 should not prevent vectorization even though iv is shared. But still, would it be better to avoid setting iv inside the loop?

[WeiqunZhang]

Maybe my last comment is not an issue. I have not noticed any performance differences in my testing.