Resolve cigar2 overflow

[jkbonfield]

This PR is does two things.

1. Fixes overflow bugs with long consecutive indels. Eg 250000D x10. We now basically fail as it represents something we cannot store in p->indel due to size limitations. It shouldn't ever happen, but I was wary of it being a vector for curious bugs given it could turn deletions into insertions and vice versa. This doesn't seem to trigger really bad behaviour with our code, but it could potentially elsewhere.

2. Refactor the resolve_cigar2 function, and try and speed it up somewhat to mitigate the performance hit of step 1 (which is surprisingly high given it's just swapping int for int64 essentially).

On short read data, this is around 8% slower (clang) and 11% slower (gcc).
On long read data it's 2% slower (clang) and 5% slower (gcc).

Note those timings are resolve_cigar2 only, measured using -fno-inline and perf record to check function counters.

[jkbonfield]

Claude review caught something more for me to explore:

Overflow check doesn't cover the full qpos computation — moderate, but relevant given the fix's purpose

if (MEX & (1<<op)) {
    p->qpos = s->y + (pos - s->x);
}
...
int ret = 1;
if (s->y > INT_MAX)
    ret = 0;

p->qpos (an int32_t) is assigned s->y + (pos - s->x), but the overflow guard only checks s->y itself. If s->y is, say, INT_MAX - 100 and (pos - s->x) is larger than 100 (which can happen for a single large CIGAR op, since op lengths can be up to ~2^28), the sum can exceed INT_MAX and silently wrap when stored into the int32_t field — while ret stays 1 (success), so the corrupted qpos is not caught and gets returned to the caller as valid.