descrypt-opencl wrongly triggers "Progress is too slow!! trying next table size."

Normally, "Progress is too slow!! trying next table size." would be triggered when there are a lot of hashes with an unsalted hash type, or for a given salt. However, it is also triggered with descrypt-opencl running against our test pw-fake-unix (3269 password hashes with 2243 different salts). I guess this is because building the per-salt kernels does indeed make the progress slow (until all kernels are built), and this confuses Sayantan's perfect hash tables code. Perhaps we should special-case this.

Also, at the default verbosity level it is no longer clear what the process is doing - it appears to be stuck for minutes. Perhaps we should print at least one informational line about building the per-salt kernels (as well as how to disable this if the startup delay is undesirable and slower long-time speed would be OK?) even at default or otherwise low verbosity levels.