…mentsAttribute (llvm#124832)"

This reverts commit 28507ac.

Well, emulation pass for `arith.fptoui` and `arith.fptosi`.

The basic algorithm looks like this:

```c
const double TWO_POW_BW = (uint_64_t(1) << bitwidth); // 2^BW

// f is a floating-point value representing the 64-bit number.
uint32_t hi = (uint32_t)(f / TWO_POW_BW);         // Truncates the division result.
uint32_t lo = (uint32_t)(f - hi * TWO_POW_BW);       // Subtracts to get the lower bits.
```

`f - hi * TWO_POW_BW` is emitted via `arith.remf`.

`arith.fptosi` emits `fptoui`  with the absolute value of the input fp. It also does a bounds check and emits `MAX_SIGNED_INT` or `MIN_SIGNED_INT` w.r.t. the sign of the input.


I added the runner tests, but here are some remarks:

According to LLVM LangRef https://llvm.org/docs/LangRef.html#fptoui-to-instruction "If the value cannot fit in target int type, the result is a poison value.". So basically, the `+-inf` and overflow values - but they result in the same poison value in the case of `fptoui` when we run it with and without emulation (see the integration test). Also, `NaN`  values result in different results with `fptosi` and `fptoui`, namely `-2^63(INT64_MIN)` and `-1` respectively. I'm not entirely sure if this is UB/poison or not.

Lastly, numbers that are representable with unsigned integers but not with signed ones (`>=2^63` in the case of `int64`) also result in poison-looking numbers: `fptosi(2^63)` emits `-2^63` with the `mlir-cpu-runner` without the emulation, which seems vague to be honest.

https://llvm.org/docs/LangRef.html#behavior-of-floating-point-nan-values also does not say much about the behavior of NaN bitcast/conversion ops. 

https://llvm.org/docs/LangRef.html#llvm-fptoui-sat-intrinsic gives saturating semantics but default lowering does not result in these. I guess not doing anything and leaving it to the specific target/lowering might emit these? Not sure...

So if I actually have to handle the cases of `abs(fp) >= MAX_SINT` in `arith.fptosi` and overflows in `arith.fptosi` are unclear. I guess the best course of action here would be that I post the PR upstream and ask for reviews over there, after your rounds of review.

coping the data)

Now the inferedAlignment variable is in bytes and not elements anymore.
This is also the case in getFromBuffer().