fix ub in lower rounding shift right

[abadams]

This is the implementation of lower_rounding_shift_right on main:

Expr lower_rounding_shift_right(const Expr &a, const Expr &b) {
    if (is_positive_const(b)) {
        ...
    }
    // Shift right, then add one to the result if bits were dropped
    // (because b > 0) and the most significant dropped bit was a one.
    Expr b_positive = select(b > 0, make_one(a.type()), make_zero(a.type()));
    return simplify((a >> b) + (b_positive & (a >> (b - 1))));
}

Consider lower_rounding_shift_right(a, (uint8)0)

The term b - 1 becomes 255, and now you have an out-of-range shift,
which causes the simplifier to inject a signed_integer_overflow
intrinsic, and compilation to fail.

This is a little annoying because if b == 0, b_positive is a zero mask,
so the result isn't used anyway (this is also why this change is legal).
In llvm, it's a poison value, not UB, so masking it off works. If the
simplifier were smarter, it might just drop the signed_integer_overflow
intrinsic on detecting that it was being bitwise-and-ed with zero.

But the safest thing to do is not overflow. saturating_add/sub are
typically as cheap as add/sub. 99.9% of the time b is some positive
constant anyway, so it's going to get constant-folded.

[abadams]

Actually bitmasking a poison value with zero in llvm produces a poison value. This bug just made llvm simplify a (randomly-generated) pipeline to a no-op.