Use copyMutableByteArrayNonOverlapping# when available

[clyring]

(The function documentation already demands "The two slices may not overlap.")

[konsumlamm]

copyMutablePrimArray, which is currently also implemented using copyMutableByteArray#, documents that the regions may overlap if the source and destination are the same array (which is the only case in which the regions can overlap). IMO copyMutableByteArray and copyMutablePrimArray should have the same behaviour, so either we change this for PrimArrays too (which would be a breaking change), or we revert this. Given that copyMutableArray also allows overlapping arrays, I tend towards the former.

[andrewthad]

You're right. I had not remember that the API of PrimArray differs slightly. There is no movePrimArray at all, and copyPrimArray is documented to handle all the cases. We should probably

1. Explicitly state that copyMutableByteArray supports overlapping arrays in the documentation.
2. Soft deprecate moveByteArray. Not a real deprecate pragma. Just a mention in the documentation that copyMutableByteArray is preferred.
3. Introduce copyMutableByteArrayNonOverlapping and copyMutablePrimArrayNonOverlapping, which will use the new primop on newer GHCs.