Optimize usage of SINGLE_HASH_MIN

As @AlekseyCherepanov noticed, running "single crack" mode against bcrypt hashes on CPU without OpenMP is wasteful because our bcrypt implementation computes 3 hashes at a time, whereas SINGLE_HASH_MIN is 8, which isn't a multiple of 3. We should probably modify the code such that it rounds to a multiple of min_keys_per_crypt.

While looking into this, I see that for logging from john.c we try and infer the chunk size using SINGLE_HASH_MIN, but the actual code in single.c is now more complicated. So we may get logging inconsistent with what we actually do next. Fixing the above issue could introduce yet another inconsistency of this sort. In particular this message might be wrong:

        if ((options.flags & (FLG_SINGLE_CHK | FLG_BATCH_CHK)) && chunk < SINGLE_HASH_MIN)
                chunk = SINGLE_HASH_MIN;
        if (chunk > 1)
                log_event("- Candidate passwords %s be buffered and tried in chunks of %d",
                        min_chunk > 1 ? "will" : "may",
                        chunk);

Review SINGLE_HASH_MIN and min_keys_per_crypt handling in single.c, then compare it with the chunk-size logging in john.c. Trace bcrypt single-crack behavior without OpenMP and the affected logging paths; done means chunking uses compatible sizes and the reported buffering behavior matches what the code actually does.