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 :)
* transaction along with its descendants, we must calculate that set of
 * transactions to be removed before doing the removal, or else the mempool can
 * be in an inconsistent state where it's impossible to walk the ancestors of
 * a transaction.)
 *
 * In the event of a reorg, the assumption that a newly added tx has no
 * in-mempool children is false.  In particular, the mempool is in an
 * inconsistent state while new transactions are being added, because there may
 * be descendant transactions of a tx coming from a disconnected block that are
 * unreachable from just looking at transactions in the mempool (the linking
 * transactions may also be in the disconnected block, waiting to be added).
 * Because of this, there's not much benefit in trying to search for in-mempool
 * children in addUnchecked().  Instead, in the special case of transactions
 * being added from a disconnected block, we require the caller to clean up the
 * state, to account for in-mempool, out-of-block descendants for all the
 * in-block transactions by calling UpdateTransactionsFromBlock().  Note that
 * until this is called, the mempool state is not consistent, and in particular
 * mapLinks may not be correct (and therefore functions like
 * CalculateMemPoolAncestors() and CalculateDescendants() that rely
 * on them to walk the mempool are not generally safe to use).
 *
 * Computational limits:
 *
 * Updating all in-mempool ancestors of a newly added transaction can be slow,
 * if no bound exists on how many in-mempool ancestors there may be.
 * CalculateMemPoolAncestors() takes configurable limits that are designed to
 * prevent these calculations from being too CPU intensive.
 *
 */
class CTxMemPool