fix: Do not panic if RHS constant in division has more bits than the operand

[aakoshh]

Description

Problem*

Resolves #8195

Summary*

Changes acir_context::euclidean_division_var to not assert that the RHS, when it's a constant, must not have more bits than the operand type, and instead it lets the runtime handle the problem.

Additional Context

In the failing program we have the following final SSA:

g0 = u16 41618

acir(inline) predicate_pure fn main f0 {
  b0(v1: u16):
    v3 = sub u16 13834, v1
    v4 = mul u16 41618, u16 41618
    v5 = mod v3, v4
    return v5
}

During ACIR generation convert_ssa_binary calls AcirContext::mul_var to handle mul u16 41618, u16 41618, which runs the following:

            (AcirVarData::Const(lhs_constant), AcirVarData::Const(rhs_constant)) => {
                self.add_constant(lhs_constant * rhs_constant)
            }

That adds an AcirVar with the value 1732057924. Then, back in convert_ssa_binary, we insert a range constraint in check_unsigned_overflow, and move on. When we handle mod v3, v4, we retrieve 1732057924 for v4, and panic because it wouldn't fit into 16 bits. But at runtime we would have failed the multiplication overflow constraint already.

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[TomAFrench]

I'm a little concerned as we'll be telling the brillig call that the inputs are a smaller size than they are in reality but we should always error beforehand.

[TomAFrench]

Perhaps we should inject a failing constraint at this point just to be sure?

[aakoshh]

I'm a little concerned as we'll be telling the brillig call that the inputs are a smaller size than they are in reality

Yes, that bothers me as well. I was wondering if it would be worth adjusting it, but then again this shouldn't actually be invoked, and I'm not sure it would even make sense or whether it could handle it.