Yen threshold differs from IJ1

[Sample Data](https://drive.google.com/file/d/1TlHlixXaKTOtpPTNgc4fqC8b3tFk0g6J/view?usp=sharing)

When using `Image > Adjust > Threshold...` and selecting `Yen` to get the ImageJ 1.x threshold on a test image, we get:

Running a simple groovy script to threshold with ops
```
#@ OpService ops
#@ ImgPlus inputData

return ops.threshold().yen(inputData)
```
on the same image produces a much more aggressively thresholded image:

I don't think this is just a different in image type because if I convert the image to 8-bit and run the IJ1 auto threshold it's actually even more generous:


However I can produce a similar image in the IJ1 auto threshold by operating on the 16-bit image and turning up the `minValue` cutoff:

It looks like the issue is that Ops is computing the min/max for the histogram off the 16-bit input but then always converts the output to 8-bit, resulting in a too-high threshold.

First converting the test image to 8-bit and then running the above script results in a reasonable output:

Reproduce the mismatch using Image > Adjust > Threshold... with Yen, the linked sample image, and the ops.threshold().yen(inputData) Groovy script. Compare the 16-bit and 8-bit outputs with ImageJ 1.x, then trace how the Yen histogram range and output type are handled. Done means the ops result matches the ImageJ 1.x threshold on the sample image.

Written by the indexing model from the issue text.