While fuzzing the RPC interface I stumbled upon a signed integer overflow in `CTxMemPool::PrioritiseTransaction(…)` which is reachable via the following two `prioritisetransaction` RPC calls:

```
$ ./autogen.sh
$ CC=clang CXX=clang++ ./configure --with-sanitizers=address,undefined
$ make
$ UBSAN_OPTIONS="print_stacktrace=1" src/bitcoind &
$ src/bitcoin-cli prioritisetransaction cafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe 0 -9123456789123456789
$ src/bitcoin-cli prioritisetransaction cafebabecafebabecafebabecafebabecafebabecafebabecafebabecafebabe 0 -9123456789123456789
txmempool.cpp:832:15: runtime error: signed integer overflow: -9123456789123456789 + -9123456789123456789 cannot be represented in type 'long'
    #0 0x5581f3e69c3c in CTxMemPool::PrioritiseTransaction(uint256 const&, long const&) src/txmempool.cpp:832:15
    #1 0x5581f3c93852 in prioritisetransaction()::$_6::operator()(RPCHelpMan const&, JSONRPCRequest const&) const src/rpc/mining.cpp:470:36
…

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior txmempool.cpp:832:15
```

Nothing high priority of course, but still worth fixing :)
* and returns false if we are the first visitor, true otherwise.
     *
     * An Epoch::Guard must be held when visited is called or an assert will be
     * triggered.
     *
     */
    bool visited(const txiter it) const EXCLUSIVE_LOCKS_REQUIRED(cs, m_epoch)
    {
        return m_epoch.visited(it->m_epoch_marker);
    }
    bool visited(std::optional<txiter> it) const EXCLUSIVE_LOCKS_REQUIRED(cs, m_epoch)
    {
        assert(m_epoch.guarded()); 
        return !it || visited(*it);
    }
};
/**
 * CCoinsView that brings transactions from a mempool into view.
 * It does not check for spendings by memory pool transactions.
 * Instead, it provides access to all Coins which are either unspent in the
 * base CCoinsView, are outputs from any mempool transaction, or are
 * tracked temporarily to allow transaction dependencies in package validation.
 * This allows transaction replacement to work as expected, as you want to
 * have all inputs "available" to check signatures, and any cycles in the
 * dependency graph are checked directly in AcceptToMemoryPool.
 * It also allows you to sign a double-spend directly in
 * signrawtransactionwithkey and signrawtransactionwithwallet,
 * as long as the conflicting transaction is not yet confirmed.
 */
class CCoinsViewMemPool : public CCoinsViewBacked