rangefeed: fix handling of aborted transactions found by txnPushAttempt

Fixes cockroachdb#35816.

The fix in cockroachdb#35777 inadvertently broke `txnPushAttempt` and its interaction with
transactions that were found to be aborted. This commit restores this handling
by reverting part of the assertion added in cockroachdb#35772 and splitting up the handling
of "aborted intents" from the handling of "aborted transactions".

Aborted transactions were always one of the most tricky situations to handle in
rangefeed. The challenge is that rangefeed may be tracking a transaction that
has been abandoned and may want to push it to unblock its resolved timestamp,
but it doesn't have a way to know where the aborted transaction's intents live
on its range. The aborted transaction record can't tell us this either. So the
only thing rangefeed can do is push the transaction and convince itself that the
aborted intents on its range can be safely ignored. This poses a problem for
accurate reference counting of intents though. We need to be able to discard a
transaction and still handle the eventual resolution of its aborted intents.

To handle this properly, the change splits up `MVCCAbortIntentOp` into
`MVCCAbortIntentOp` and `MVCCAbortTxnOp`. Before this change, the single
operation type was attempting to fill both roles, but they mean fundamentally
different things. `MVCCAbortTxnOp` is then given back its ability to delete
transactions from the queue directly without worrying about their reference
count. Next, the `unresolvedIntentQueue` is extended to be a little more
flexible. Instead of asserting that reference counts never drop below zero, it just
ignores changes that would make reference counts negative. This has the potential
to "leak" reference counts that saturate at zero and are then incremented again,
but we know that this will only ever happen for aborted transactions, which can
always be pushed again to rediscover that they have been aborted.

Release note: None