QuantOps verifier asserts that quant scale is below 1e+10
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this [failed invocation](https://github.com/tensorflow/tensorflow/pull/62604/checks?check_run_id=19477354951) of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request. As @pkgoogle  was already so kind to help me with #62196 , I decided to tag him here too. 

I worked on the bug and created a draft PR. The main culprit for the spurious transformation are the pathological quantization scales. See below for an example of the MLIR debug output:
```
 %22 = "tfl.quantize"(%21) {qtype = tensor<1x64x112x112x!quant.uniform<i8:f32, 1.3344405750530544E+36:127>>, volatile} : (tensor<1x64x112x112xf32>) -> ...
```
I have added a verification check aborting the quantization if the scale parameter exceeds `1e+10`. TF [already considers](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/compiler/mlir/lite/quantization/quantization_utils.h#L307) a quantization scale above `1e+1` problematic, and the [SmoothQuant paper](https://arxiv.org/abs/2211.10438) considers values of `7e+1` (for foundation models) to pose serious challenges. 

The original [gist.py](https://colab.research.google.com/gist/pjpratik/f71dec9bd1f702c1a62fb8505b7d4a50/62196.ipynb) produces the following output when run with the code from the PR:
```
RuntimeError: Failed to quantize: <unknown>:0: error: loc("PadV2/constant_values"): 'tfl.quantize' op Quant scale (1.334441e+36) too large
<unknown>:0: note: loc("PadV2/constant_values"): see current operation: %4 = "tfl.quantize"(%3) {qtype = tensor<!quant.uniform<i8:f32, 1.3344405750530544E+36:127>>, volatile} : (tensor<f32>) -> tensor<!quant.uniform<i8:f32, 1.3344405750530544E+36:127>>
```

The draft PR also contains a test. In addition to the submitted code, I would still like to add the following:
- Tests for `tfl.quantize` with `UniformQuantizedPerAxisType` quantization
- Verifier for DequantizeOp and associated tests
- End2End tests?

Before adding the functionality above, I would like to ask you two questions for clarification: 
- Do you agree with the broad contours of this PR, or have suggestions? 
- The tests I added (`@satisfy{violate}Threshold`)do not produce any output. (Verify this by running `./bazel-bin/tensorflow/compiler/mlir/tf-opt  -verify-diagnostics -tfl-runtime-verify tensorflow/compiler/mlir/lite/tests/ops.mlir > ops_output.mlir` and see that the tests are missing). I'm surprised by this but realize that `@testQuantizedResizeNearestNeighbor` does not produce output, while `@testQuantize` does. Can you explain the different behavior of the two tests, what I need to do for @satisfyThreshold to be printed, and (just for my understanding) what utility the test of @testQuantizedResizeNearestNeighbor has if it does not produce any output?

I am also tagging @jpienaar  here. He kindly answered an [MLIR question](https://discourse.llvm.org/t/what-impact-does-a-failing-op-verifier-have-on-the-optimization-process/75450) I had, and I thought it might be worthwhile to add him too. 





Addresses #62196 

In some situations, the tf-tfl converter can produce spurious quantization scales. The conversion nevertheless passes, but the tensorflow lite interpreter aborts when allocating tensors for the model.  The PR adds a verification check for the mlir QuantOps (and DequantizeOps) ops. 