[FEATURE] Iterate payload combinations in a random order

[mazzz3r]

Please describe your feature request:

Add an opt-in flag that iterates a template's payload combinations in a random order instead of the sequential order of the payload sets. Every combination is still produced exactly once — only the order changes. Proposed as -pro, -payload-random-order, default off.

Today the payloads + attack iterators (batteringram, pitchfork, clusterbomb) walk the sets in a fixed order. clusterbomb increments them like an odometer, so the innermost set varies fastest and combinations that share a value are produced back to back. Two runs over the same sets send the combinations in the same order, clustered at the start of each wordlist.

Describe the use case of this feature:

The order matters whenever a run doesn't send every request, or when the sequence itself is watched:

• Rate limits, -stop-at-first-match, and interrupted runs mean only a prefix of the combinations goes out. With the sequential order that prefix is always the top of the wordlists, so a partial scan keeps probing the same corner of the space; a random order turns any prefix into a representative sample of the whole set.
• clusterbomb sends every password for one username in a row. Against per-account lockout or throttling, that burst burns through one account before moving to the next. A random order spaces out the attempts that share a username (or a path, or a Host header).
• A wordlist-ordered sequence is easy to fingerprint and throttle; a shuffled one is less predictable.

Alternatives that don't cover it:

• Shuffling each payload file by hand breaks pitchfork, which pairs by index — shuffling the files independently changes which pairs are tested — and still sends clusterbomb in odometer order over the shuffled values.
• Shuffling only the innermost set leaves the outer sets sequential, so combinations that share an outer value still cluster.

A flag that shuffles the combination order while keeping each attack type's set of combinations covers both cases. Total() does not change, so -stats/progress counts stay correct, and the default stays sequential.

The implementation is in #7914

[mazzz3r]

Implemented and merged #7914.