[poly]: `heir-polynomial-to-llvm` sometimes requires 128-bit math, should have the option to avoid it

The naive lowering of poly to llvm can require 128-bit ops if the `cmod` is bigger than 32 bits (i.e., two 64-bit ints required to represent a coefficient, which get multiplied to a 128-bit result before being modded back to `cmod`).

Some platforms and architectures don't have 128-bit math intrinsics, and when this project's tests use `mlir-cpu-runner` on such a platform, it fails with a message like this before exiting.

```
JIT session error: Symbols not found: [ __modti3 ]
```

(`modti3`) is the intrinsic for 128-bit integer division.

It seems reasonable that (even if this test weren't failing on Google's internal CI :wink:) we should allow this pass to emulate wide-int ops with lower-width intrinsics. This is supported by MLIR via the `-emulate-wide-int` pass. However, that pass happens to not support `arith.subi` at the moment, which our lowering uses. So I commented out the test that used 128-bit math in https://github.com/google/heir/pull/203 and we can add it back after upstreaming support for `subi`.

Adding it would involve something like this in `heir-opt.cpp`, with some additional plumbing to allow the user to specify their platform's widest supported int.

```
arith::ArithEmulateWideIntOptions emulateWideIntOptions;
emulateWideIntOptions.widestIntSupported = 64;
manager.addPass(arith::createArithEmulateWideInt(emulateWideIntOptions));
```