added sorting algorithm

[gmacgilchrist]

Just pushing this initial commit to test workflow.

I have written a subroutine called sort_scalar_k, which is just a copy of the convective_adjustment bubble sorting algorithm, but designed to search through temperature and return only the sorted index ksort, nothing is done to the temperature field itself.

The code has not been tested, but it does compile.

Some outstanding questions:

1. How to do generalize this for an arbitrary tracer in the ocean?
2. The algorithm builds a 3d array, ksort. Would it perhaps be better if the subroutine operated on a single column, which could be called at some point in the grid building step (avoiding allocation of a full 3d array)?
3. At present it follows convective adjustment by sorting everything to be monotonically increasing from surface to depth. This will mean inverting the whole water column in some places for temperature, which is likely to be inefficient. Perhaps functionality to choose it to be increasing or decreasing with depth would be valuable.

[ashao]

1. To generalize this, replace the tv argument with something else (for some reason I always use phi for arbitrary tracers). Whoever uses this function is then responsible for passing in the desired scalar.
2. I think you're right that this subroutine should just work on a single column. I mean at some point, we'll have to store a 3D array, but it's probably better do that higher up in the call stack. There's a little bit of a push to columnarize (I think people refer to this as kernelizing?) some of these more basic routines for optimization purposes.
3. That's interesting point. I think though that the build_and_interpolate_grid expects it to be monotonically increasing with k-space. If you want to make this more generally useable within MOM6, it would be good to have a separate (maybe optional argument?) to specificy the direction of monotonicity.