Fix launch parameter heuristic exceeding the maximum number of threads per block

[luraess]

This PR fixes the issue that compute_nthreads could return more than nthreads_max threads per block, making kernel launches fail, e.g. for maxsize = (256, 5, 128):

nthreads = (32, 5, 2) = 320 > NTHREADS_MAX = 256
ERROR: Number of threads per block exceeds kernel limit

Any 3-D call is affected whose largest array argument has an extent of 3, 5, 6 or 7 in y (e.g. a 256x4x128 grid, where a y-staggered field is of size 256x5x128). The memopt path is affected as well, as it uses the same heuristic (with nthreads_max = 128 for CUDA).

The thread budget of each dimension was rounded up (ceil). Whenever a dimension was clamped to a smaller maxsize, the next dimension's share was no longer an integer and rounding it up exceeded the remaining budget; prod(nthreads) <= nthreads_max was never verified afterwards.

Fix

Rounding the budget of each dimension down instead, which makes prod(nthreads) <= nthreads_max hold by construction:

nthreads_y = min(max(floor(Int,nthreads_max/nthreads_x), 1),              ...)
nthreads_z = min(max(floor(Int,nthreads_max/(nthreads_x*nthreads_y)), 1), ...)

The heuristic is unchanged for all inputs that did not overflow: a sweep over maxsize in [1,300]x[1,80]x[1,80] for the CUDA, AMDGPU and memopt parameterisations shows that the differing inputs are exactly the previously overflowing ones (267198 of them for CUDA), and that the maximum total is now exactly nthreads_max. The example above now gives (32, 5, 1).

I've added a new compute_nthreads testset in test/ParallelKernel/test_parallel.jl covering the documented cases, the regression itself, and sweeps asserting prod(nthreads) <= nthreads_max and nthreads >= 1 for the CUDA, AMDGPU and memopt parameterisations.

cc @ChristianSchuler

[omlins]

LGTM, thanks!