This PR makes the following improvements to `vector.scatter` and its
lowering pipeline:
- In addition to `memref`, accept a ranked `tensor` as the base operand
of `vector.scatter`, similar to `vector.transfer_write`.
- Implement bufferization support for `vector.scatter`, so that
tensor-based scatter ops can be fully lowered to memref-based forms.

It's worth to complete the functionality of map_scatter decomposition.
Full discussion can be found here:
https://github.com/iree-org/iree/issues/21135

---------

Signed-off-by: Ryutaro Okada <1015ryu88@gmail.com>

Reland pass and fix linker errors.

---------

Co-authored-by: Maksim Levental <maksim.levental@gmail.com>

Reverts llvm/llvm-project#167608

Broken builder https://lab.llvm.org/buildbot/#/builders/52/builds/12781

Fix both symbol visibility issue in the mlir_apfloat_wrappers lib and the linkage issue in ArithToAPFloat.

Reverts llvm/llvm-project#167436 to fix sanitizers

Reland https://github.com/llvm/llvm-project/pull/166618 by fixing
missing symbol issues by explicitly loading
`--shared-libs=%mlir_apfloat_wrappers` as well as
`--shared-libs=%mlir_c_runner_utils`.

This reverts commit 0e639ae6e030ade849fa7a09cb7dc40b42f25373.

Reland https://github.com/llvm/llvm-project/pull/166618 with
MLIRFuncUtils linked in.

This reverts commit 222f4e494a0cd9515c242fd083c2776772734385.

This commit adds a new pass that lowers floating-point `arith`
operations to calls into the execution engine runtime library. Currently
supported operations: `addf`, `subf`, `mulf`, `divf`, `remf`.

All floating-point types that have an APFloat semantics are supported.
This includes low-precision floating-point types such as `f4E2M1FN` that
cannot execute natively on CPUs.

This commit also improves the `vector.print` lowering pattern to call
into the runtime library for floating-point types that are not supported
by LLVM. This is necessary to write a meaningful integration test.

The way it works is 

```mlir
func.func @full_example() {
  %a = arith.constant 1.4 : f8E4M3FN
  %b = func.call @foo() : () -> (f8E4M3FN)
  %c = arith.addf %a, %b : f8E4M3FN
  vector.print %c : f8E4M3FN
  return
}
```

gets transformed to

```mlir
func.func private @__mlir_apfloat_add(i32, i64, i64) -> i6
func.func @full_example() {
  %cst = arith.constant 1.375000e+00 : f8E4M3FN
  %0 = call @foo() : () -> f8E4M3FN
  // bitcast operand A to integer of equal width
  %1 = arith.bitcast %cst : f8E4M3FN to i8
  // zext A to i64
  %2 = arith.extui %1 : i8 to i64
  // same for operand B
  %3 = arith.bitcast %0 : f8E4M3FN to i8
  %4 = arith.extui %3 : i8 to i64
  // get the llvm::fltSemantics(f8E4M3FN) as an enum
  %c10_i32 = arith.constant 10 : i32
  // call the impl against APFloat in mlir_apfloat_wrappers
  %5 = call @__mlir_apfloat_add(%c10_i32, %2, %4) : (i32, i64, i64) -> i64
  // "cast" back to the original fp type
  %6 = arith.trunci %5 : i64 to i8
  %7 = arith.bitcast %6 : i8 to f8E4M3FN
  vector.print %7 : f8E4M3FN
}
```

Note, `llvm::fltSemantics(f8E4M3FN)` is emitted by the pattern each time
an `arith` op is transformed, thereby making the call to
`__mlir_apfloat_add` correct (i.e., no name mangling on type necessary).


RFC:
https://discourse.llvm.org/t/rfc-software-implementation-for-unsupported-fp-types-in-convert-arith-to-llvm/88785

---------

Co-authored-by: Matthias Springer <me@m-sp.org>