Clustering index descending from 0

[Baharis]

Following #2311 and discussion therein, this PR suggests indexing clusters created by dials.combine_experiments from largest to smallest as well as indexing from 0 instead of an arbitrary integer, which depends on other phil parameters. Additionally, I took the liberty to rewrite the _save_output method and nested save_in_batches function, as the previous implementation of the latter was fairly difficult to read.

This PR requires #2311 to be merged before it to avoid undefined variable error. Afterwards, I also need to perform a test or two to check whether everything behaves as expected.

[Baharis]

I hoped I'll be able to solve the issue myself, but I am at loss. I have prepared this branch to reverse the clustering order, so that the largest cluster is indexed 0, second largest is indexed 1 and so on. This code failed 3 tests: 2 of them relied on old naming scheme, and this was easy to fix.

Unfortunately, this PR also causes test_combine_imagesets to fail for a reason, which I do not fully comprehend. It is expected that reflections with "id" == -1 will preserve it during combining (see #1760). However, my tests show that "id" == -1 on my branch is not preserved, but rather set =="imageset_id". I do not understand the reason behind this behavior. I tried looking for it in the code, but I have problems understanding the changes introduced by #1760.

@ndevenish, do you maybe happen to have an idea why saving combined files with different names influences refl indexing?