Decide on (not) unifying effectively-same salts of salt-only formats

As mentioned in comments in #5720 and #5730, the commit 6c82f3aa76cdd78cf79d23f3c182c53ad791653b for the BitShares format results in correct de-duplication of effectively-same non-hashes at loading and cracking, but then --show and a second cracking run do not recognize the pot entry as matching also the other non-hash. So this may not be the way to go (one other way would be to unify in split rather than in get_salt), or maybe we need more changes.

Once we agree on how we'd like this to work, we could implement the same in the Bitcoin[-opencl] formats. (Are there any others needing it?)

Right now, for Bitcoin the behavior is similar to what it was for BitShares prior to the mentioned commits - the effectively-duplicate non-hashes are loaded as two distinct ones, cracked correctly (but with double the effort), and then indeed reported correctly. Ideally(?), we'd de-duplicate at load time, but without the subsequent drawbacks.

The simplest "fix" is to decide not to bother, and either to revert the referenced commit or just accept that if someone has both forms of such non-hashes, they may end up wasting effort on double the computation.

Start by reviewing commit 6c82f3aa76cdd78cf79d23f3c182c53ad791653b and the related comments in #5720 and #5730. Compare the described BitShares and Bitcoin[-opencl] loading, cracking, --show, and second-run behavior. Done means the project has an agreed deduplication policy and the affected formats consistently follow it.