Add manual exploit-sector, target-sector, and thread-count control flags

[doomfrawen]

Summary

Previously the tool always auto-picked the exploit (pivot) sector via `find_exploit_sector()` (the highest-numbered sector with a known key) and always attacked every sector still missing a key, with no way to override either choice. It also always used `num_CPUs()` logical cores with no way to change the worker thread count.

Adds three flags, all off by default (existing auto-detect behavior is unchanged unless one is passed):

• `-e ` - force this sector as the exploit/pivot sector (errors out if it has no known key)
• `-s <sector[,sector...]>` - only attack the listed sector(s), instead of every sector still missing a key
• `-j ` - override the worker thread count instead of the auto-detected logical CPU count

`-j` is implemented as a single override point in `num_CPUs()` (`util.c`), so it changes both the bit-flip-property threads and the hardnested brute-force worker threads consistently, without touching every call site individually.

`-s` only filters the (expensive) nested/hardnested recovery loop, not the initial default-key sweep - the sweep needs to check every sector regardless, since `find_exploit_sector()` (or `-e`) depends on knowing which sectors already have a default key.

Test plan

Tested on real hardware (MinGW-w64 + libnfc + PC/SC reader, MIFARE Classic 1K card, Intel i7-8650U/4C8T):

• `-h` shows the new flags correctly
• `-e 4` forces sector 4 as the exploit sector ("forced via -e"), validated it must already have a known key
• `-s 1` restricts the attack to only sector 1, skipping other unknown sectors
• `-j 4` runs with 4 worker threads instead of the auto-detected 8, confirmed via the "Start using N threads" message and a measurable (not crash-related) benchmark throughput difference consistent with this CPU's 4 physical cores
• All three flags combined together, plus `-Z`, in a single run with no crash