bcrypt-opencl autotuning

Inspired by hashcat's tweet/commit:

https://twitter.com/hashcat/status/1107399818740203520
https://github.com/hashcat/hashcat/commit/5ecbcde94515a31113bc2d33a5188ffcbe2e7dcf

which does basically:

   fixed_local_size = (device_param->device_local_mem_size - 4) / 4096;

I took a look at what we do in JtR. Turns out, we do have similar LWS autotuning since commit efd44decdd75436fe7df0e01d9882e3589c0be2f back in 2013. However, instead of directly calculating the max LWS that fits, we halve the LWS until it fits:

        const int       lmem_per_th = ((1024 + 4) * sizeof(cl_uint) + 64);
[...]
        if ((get_device_type(gpu_id) != CL_DEVICE_TYPE_CPU) &&
            lmem_per_th < get_local_memory_size(gpu_id))
                while (local_work_size >
                       get_local_memory_size(gpu_id) / lmem_per_th)
                        local_work_size >>= 1;

I guess we could gain some performance by directly setting LWS to the maximum that fits, like hashcat does now. For example, on GTX 1080 we're now getting:

ptxas info    : Used 72 registers, 32772 bytes smem, 376 bytes cmem[0]

Notice that this is 32K + 4 bytes. On this device, we could probably go up to 48K-4K. (It's a pity that 4 bytes are somehow lost, just like in hashcat. Ideally, we'd also figure this out and avoid it, which would let both projects fit an extra instance of bcrypt in the last 4K.)

Also, we have a hardcoded maximum GWS of 4096, which isn't necessarily optimal. We should improve bcrypt-opencl's GWS autotuning as well.

Edit: see also: #2620 #3638.

Start by locating bcrypt-opencl's existing local-work-size autotuning and the hardcoded global-work-size limit of 4096. Read the referenced hashcat commit and compare how the current code derives local memory limits. Done means selecting a fitting maximum LWS and improving GWS autotuning, with performance checked across relevant devices.