Add quantize operator (bf16->int8)

[albiol2004]

Description:

Add a quantize operator that converts bfloat16 tensors to int8 with per-group symmetric scaling. Basically counterpart to #95

Together with INT8 GEMM (#93), this completes the W8A8 quantized inference pipeline on the NPU:

bf16 activations → quantize (bf16→i8) → INT8 GEMM (i8×i8→i32) → dequant (i32→bf16) → bf16

Proposed behavior:
- Input: bfloat16 tensor + group_size parameter
- Output: int8 tensor + bfloat16 scale factors (one per group)
- Scaling: symmetric, per-group, scale = max(abs(group)) / 127, out = clamp(round(in / scale), -128, 127)
- Follows the dequant_i32 operator pattern (custom MLIROperator with mixed input/output dtypes)

Related:
- #93 : INT8 GEMM support
- #95 : Dequant i32→bf16 operator
- Existing iron/operators/dequant/ (int4→bf16) and iron/operators/dequant_i32/ as implementation references

[AngryLoki]

Q: does is make sense to add such granular Python operators to IRON? From what I remember, there is a large penalty for kernel switching on XDNA, also it does not reduce memory bandwidth, so that after combining it as described above, it will be massively slower than on CPU.

Or these operators are not for end users, and end users should do something else (namely, build fused operators that combine all fusable ops, incl. post-ops, if any)?

[albiol2004]

Q: does is make sense to add such granular Python operators to IRON? From what I remember, there is a large penalty for kernel switching on XDNA, also it does not reduce memory bandwidth, so that after combining it as described above, it will be massively slower than on CPU.

Or these operators are not for end users, and end users should do something else (namely, build fused operators that combine all fusable ops, incl. post-ops, if any)?

I am basically trying to do what FastFlowLM does, and in my head the best way was to build all the foundation blocks first. I am very new to AMD NPUs so I ran into that wall while experimenting. You're absolutely right, fused kernels is the way to go. I tested on the Llama example with INT 8 quantization for all distinct GEMM operations and it was even slower than BF16. I then vibe coded a fused kernel for them and there it clicked. But I still feel like adding the basic operators is the foundation of it. Imagine a runtime which has all the base operators for LLMs and also most of the most common fused kernels. If a new model is created, at least you have default support for it although very slow (and even probably better running some of those on CPU). Does it make sense? I'll close this PR and be more selective with operators, but still keep a library of these in a fork