Consider salt progress for ETA

[solardiz]

As I suggested in https://www.openwall.com/lists/john-users/2023/11/15/2

We'd need the calculation to consider progress at processing more salts within the current batch of password candidates. Maybe instead of the actual number of candidate passwords processed, we could use a virtual number scaled by the ratio of salts processed so far. In other words, in p/s and ETA instead of the actual but lagging p, we could use p + kpc*saltn/salts. As a special case, on interrupt/restore we'd need to infer the number of previously processed salts. Another special case is "single crack" mode, where we should omit this logic.

Alternatively, as magnum suggested, we should at least mute ETA until the first block of candidates has been processed or if it matches the current time.