Option to specify GPU usage intensity

Our formats typically use 200 milliseconds as the maximum OpenCL kernel duration for auto-tuning, passing this number into autotune_run. Perhaps we can have autotune_run adjust this value based on a command-line option, e.g. --intensity=2 would double it, making most kernels tune to up to 400 ms. We can also accept e.g. --intensity=0 or --intensity=0.5 for halving the maximum kernel duration.

This is probably similar to what hashcat does with its -w option.

Right now, we can adjust this with LWS / GWS env vars or --lws / --gws command-line options, but these are trickier to use and their optimal values differ per-device and per-format. I think we need to provide an easier to use option.

For a specific example, (with the changes I'm about to commit for the shared SHA-2 code) bitcoin-opencl achieves this on Vega 64 by default:

LWS=256 GWS=16384 (64 blocks) DONE
Speed for cost 1 (iteration count) of 200460
Raw:	4369 c/s real, 327680 c/s virtual

but with the limit increased to 400 ms it's this:

LWS=256 GWS=131072 (512 blocks) DONE
Speed for cost 1 (iteration count) of 200460
Raw:	4691 c/s real, 3276K c/s virtual

I think it'd be intuitive for a user to request --intensity=2 (or higher) for all (maybe different) GPUs on a headless system. It's less intuitive to guess there's improvement by manually doubling GWS a few times, and the resulting values would need to be managed per-GPU.

In the specific example above, I was wondering whether I should lower HASH_LOOPS, but somehow lowering it from 2000 to 500 didn't result in a similar increase in GWS, but instead resulted in a decrease in LWS and in lower speed (with the limit at 200 ms):

LWS=64 GWS=16384 (256 blocks) DONE
Speed for cost 1 (iteration count) of 200460
Raw:	4300 c/s real, 96376 c/s virtual

So it does appear that we need to allow more than 200 ms sometimes.

Start by locating autotune_run and the existing --lws/--gws command-line option handling. Trace how the 200 ms maximum kernel duration reaches the OpenCL auto-tuning paths, then determine where an --intensity value should scale it. Done means integer and fractional values adjust the limit consistently without breaking existing options, with the relevant behavior covered by the project's tests or validation.