[Perf experiment] Make checked unsigned add not use intrinsics in debug mode

**NOT MEANT FOR MERGING YET**

This PR replaces unsigned checked addition LLVM intrinsic with simpler, inline implementations *in debug mode*.

# Motivation

According to the [LLVM performance tips]( https://llvm.org/docs/Frontend/PerformanceTips.html), arithmetics intrinsic (including overflow checks) should be avoided if possible, since the optimizer is not as good at reasoning about them:
> Avoid using arithmetic intrinsics unless you are required by your source language specification to emit a particular code sequence. The optimizer is quite good at reasoning about general control flow and arithmetic, it is not anywhere near as strong at reasoning about the various intrinsics. If profitable for code generation purposes, the optimizer will likely form the intrinsics itself late in the optimization pipeline. It is very rarely profitable to emit these directly in the language frontend. This item explicitly includes the use of the overflow intrinsics.

The goal of this PR is to check if using a simple, inline implementation of overflow checks is beneficial for compile times, compared to just using the intrinsic.

From my research, in debug mode, the runtime performance of manual overflow checks is comparable to the performance of intrinsics.

I will perform a perf run to see if:
1. This PR improves compiletimes.
2. This PR does not degrade debug runtime performance in a noticeable way.

# Implementation

The inline overflow checks are performed by comparing the sum of two numbers to the result of or-ing them together.
The sum `a + b` is smaller than `a | b` if and only if an overflow occurs. This is used to detect overflows.

[Perf experiment] Make checked unsigned add not use intrinsics in debug mode

**NOT MEANT FOR MERGING YET**

This PR replaces unsigned checked addition LLVM intrinsic with simpler, inline implementations *in debug mode*.

# Motivation

According to the [LLVM performance tips]( https://llvm.org/docs/Frontend/PerformanceTips.html), arithmetics intrinsic (including overflow checks) should be avoided if possible, since the optimizer is not as good at reasoning about them:
> Avoid using arithmetic intrinsics unless you are required by your source language specification to emit a particular code sequence. The optimizer is quite good at reasoning about general control flow and arithmetic, it is not anywhere near as strong at reasoning about the various intrinsics. If profitable for code generation purposes, the optimizer will likely form the intrinsics itself late in the optimization pipeline. It is very rarely profitable to emit these directly in the language frontend. This item explicitly includes the use of the overflow intrinsics.

The goal of this PR is to check if using a simple, inline implementation of overflow checks is beneficial for compile times, compared to just using the intrinsic.

From my research, in debug mode, the runtime performance of manual overflow checks is comparable to the performance of intrinsics.

I will perform a perf run to see if:
1. This PR improves compiletimes.
2. This PR does not degrade debug runtime performance in a noticeable way.

# Implementation

The inline overflow checks are performed by comparing the sum of two numbers to the result of or-ing them together.
The sum `a + b` is smaller than `a | b` if and only if an overflow occurs. This is used to detect overflows.