Fixed issue with time triple merging with realizations

This PR fixes a serious problem in merge. When attempting to merge a complex set of data with various times forecast periods and forecast reference times, merge is amazingly clever at turning this into a multidimensional cube with the different coordinates along different dimensions. When some data is missing or just doesn't quite fit the pattern, merge does the sensible thing and stacks everything up, forming so-called combinations. All is well so far. However, in this second case where the time like coordinates all lie along a single dimension things go wrong with the process if there are groups of the time-like scalars that correspond to another scalar. For example, if there is a sequence of time, forecast period and forecast reference time that repeats for a number of realisations. A bug means that the size of the time-like dimension is multiplied by the number of realisations and garbage is found in the extra uninitialised bits of the coords/data array.

The fix is easy, use a set to get the unique combinations of time-like tuples. I've also sorted this set of unique cells to fix the order. This fix has changed the order of lat-lon slices in some of the results as you can see in the diffs.

I've put the testing into integration rather then modifying the old style test_merge.py file.