Optimize removal of current salt during cracking

[timc995]

crk_remove_salt() currently searches the salt list from the head each time
a salt is removed. With very large numbers of unique salts and a candidate
that cracks many of them, this produces near-quadratic behavior.

This change tracks the link pointing to the currently processed salt in
crk_salt_loop(), allowing the normal current-salt removal path to unlink it
in O(1). The existing list search remains as a fallback for other callers.

I encountered this with a dynamic format where each username effectively
forms a unique salt.

Benchmarks:

~500k unique salts, 2,783 cracks

• before: 7m45s
• after: 1m07s

~1M unique salts, 5,459 cracks

• before: 29m38s
• after: 2m11s

~1M zero-hit baseline

• about 2m14s

Correctness check:

• patched and unpatched 1M runs both produced 5,459 cracks
• sorted pot files were identical (diff produced no output)

[solardiz]

Wow. Thanks. I wonder how this remained that way for so long. I guess we were primarily testing crack removal speed with large unsalted hash lists, and secondarily perhaps with descrypt where it's 4096 salts.