Fix ROI edits disappearing on MacOS

[daljit46]

This small change fixes #2319.
After the discussion this morning with @bjeurissen, I decided to investigate this long-standing issue in the viewer. So this wasn't really a driver issue as discussed in the relevant issue, but an error in our code.
After tinkering with OpenGL code a bit, I noticed that the undo/redo shader in undoentry.cpp was using an integer sampler to read the values from the texture.
Our texture data type is GL_R8, which is an 8-bit normalised fixed-point format. It needs a float sampler, because integer samplers are for integer formats like GL_R8I.

@MRtrix3/mrtrix3-devs should we include this fix in 3.0.8?

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[Lestropie]

If it's a bug fix, then it should be targeting master, whether it gets merged in time for 3.0.8 or not.

I worry here that the fix is being applied at the wrong end & in the wrong direction. The ROI tool deals exclusively with bitwise data and no interpolation. It would make a lot more sense to be using 8-bit integer data. It's more likely that it's the upstream texture data type that's the bug, not the downstream sampler.

[daljit46]

If it's a bug fix, then it should be targeting master, whether it gets merged in time for 3.0.8 or not.

Will rebase this on top of master.

I worry here that the fix is being applied at the wrong end & in the wrong direction. The ROI tool deals exclusively with bitwise data and no interpolation. It would make a lot more sense to be using 8-bit integer data. It's more likely that it's the upstream texture data type that's the bug, not the downstream sampler.

We could use an integer texture, but more changes would be needed.
With the current proposal, since we're storing 0 or 1, in the shader (texelFetch()) we'll either get 0.0 or 1/255, which will get quantised to 0 or 1 as expected once we read back to CPU. So I don't think there's any danger in using a fixed-point texture here.
If we decide to change the texture format to an integer one, I think we may need to think about the interaction of the ROI texture code with the rest of the rendering code, which operates assuming non-integer samplers. I don't think the changeset should be too big, so if we want this for better code clarity and intent, I'm happy to do that.

[Lestropie]

Given that the various tools operate sequentially and independently with their own shaders, I would have thought it not too difficult, but I'm admittedly highly out of practise with the GUI code. Maybe have a dig at it, but if you encounter anything that looks like it could gobble up a lot of time revert back to the one-line fix?

[daljit46]

This is now targeting master.

I changed the format for the ROI texture from GL_R8 to GL_R8UI. The changes are still minimal. A noteworthy change is in slice.cpp, where the slice shader must sample it with an integer sampler and convert that integer into a float mask for the rest of the float-based rendering pipeline. So I modified the fragment shader to use usampler3D for ROI volumes and sampler3D for normal float volumes. Future code needs to take care of using the correct (integer) sampler when interacting with the ROI texture.