Review our use of exit codes

Review our use of exit codes. Specifically, the --max-run-time and --max-candidates options currently exits with 1 [EXIT_FAIL] unless the session actually ended despite them. While 0 [EXIT_SUCCESS] is not an alternative for scripting purposes, we might want to use a third alternative.

hashcat has these (docs/status_codes.txt):

-2 = gpu-watchdog alarm
-1 = error
 0 = OK/cracked
 1 = exhausted
 2 = aborted
 3 = aborted by checkpoint
 4 = aborted by runtime

I'm not sure I'm a fan of returning EXIT_FAIL if we exhausted the keyspace but I have to admit our current exit codes are worse - from JtR a script can't tell the difference between "no hashes loaded", "all hashes cracked" and "cracking session finished with uncracked hashes left"

Start by reading docs/status_codes.txt and trace how --max-run-time and --max-candidates currently produce exit status 1. Compare the existing outcomes described in the issue and decide which distinct statuses scripts need. Done means the exit codes distinguish exhaustion, successful cracking, aborted sessions, and runtime or candidate limits without conflating unrelated outcomes.