Reuse cache-friendly approach from md5crypt-long in OpenCL

Quoting @solardiz from https://github.com/magnumripper/JohnTheRipper/pull/3930

Curiously, md5crypt-long is now ~45% faster than the more-optimized md5crypt format on this UltraSparc T5 system I'm testing on. I tried disabling MD5_X2, but this made little difference. I suspect it has to do with other load on the system (it's not otherwise idle at all, with load averages around 15.0 on the 64 logical-CPU system) running its own hardware threads and thus constantly competing for the tiny L1 data caches. This CPU only has 16 KB of L1 data cache per 8 hardware threads, so only 2 KB per thread. Our optimized md5crypt format uses 8 pre-filled MD5 buffers, so ~512 bytes. Our md5crypt-long format, even after optimizations in this PR, has a smaller L1 working set size. Although its buffer is of similar size, it only fills and reads back from the initial portion of the buffer depending on actual password length (and my performance comparison here is for length 7), and then works with just one MD5 context. So for length 7 it probably needs something like 100 bytes.

We should consider reusing this trick in OpenCL. Maybe it'd result in lower GWS becoming more optimal, with the buffers still in cache.

Compare the md5crypt-long and md5crypt OpenCL implementations, focusing on their buffer usage and MD5 contexts. Benchmark different password lengths and global work sizes; done means the cache-friendly approach is reused and demonstrates improved performance or lower optimal GWS.