dirmerge: Better selection of first volume

[Lestropie]

Did this in addition to #2749 as I needed to modify the gradient table for the local primary project and therefore figured I'd address this annoyance as well.

Previously, the first volume in the output scheme was chosen as a random volume from the first subset of the first shell. Here, this is modified to instead be a random volume from the largest subset of the largest shell. This should slightly improve the quality of distribution of bmax volumes across the acquisition time.

Closes #2677.

@jdtournier: I've only tested this with my own usage of dirmerge, which doesn't involve multiple subsets as input (since Siemens can't interleave phase encoding directions). Do you have data lying around that you can feed into this modified version? Otherwise I'll have to synthesize something, as there's no committed test data for this command.

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"

[Lestropie]

Created data to verify command operation. Tests aren't self-validating, they only test for successful execution, but the example outputs should show the difference resulting from the proposed change (see example below). Also made the old behaviour accessible via new command-line option.

---

For requesting 8 b=0, 12 b=300, 24 b=1000, 60 b=3000:

Old behaviour / with -firstisfirst:

   0.000000000000000    0.000000000000000    0.000000000000000     0
  -0.245334728765522   -0.728674792404530   -0.639409037921550  3000
   0.384756515209046    0.777963368558556   -0.496724693552893  1000
   0.325554213513894   -0.626013148535972    0.708605667436712  3000
   0.434562166848720   -0.669611329169057   -0.602309215430242   300
  -0.914625279504782   -0.028034163490006    0.403329497766052  3000
   0.223783129583119    0.950869945098472   -0.213933303677606  3000
  -0.785950063156333   -0.149923498729031   -0.599837847049853  1000
   0.844251651261712    0.040702844155578    0.534399127824438  3000
   0.206901969593378   -0.046465456683910   -0.977257661169017  3000
  -0.668588638606269    0.490110982821053    0.559267786346396  1000

New behaviour:

   0.225305116653016   -0.938181788409132   -0.262778492855511  3000
   0.384756515209046    0.777963368558556   -0.496724693552893  1000
   0.434562166848720   -0.669611329169057   -0.602309215430242   300
  -0.336469676700788    0.281618308538067   -0.898598511548414  3000
   0.000000000000000    0.000000000000000    0.000000000000000     0
   0.939811749437261    0.289922903888099   -0.180827501837435  3000
  -0.527751355747147    0.195325352568425    0.826635659254468  3000
  -0.785950063156333   -0.149923498729031   -0.599837847049853  1000
   0.545490507742794    0.559552335476646    0.623972186740034  3000
  -0.267538570147118   -0.815654390766691    0.512962989217209  3000
  -0.668588638606269    0.490110982821053    0.559267786346396  1000

With the new code, the first volume is b=3000 as that's the shell with the most volumes and therefore the one that results in the least bias in terms of subsequent number of volumes left remaining to acquire across shells.

(One can make an argument that b=0 volumes warrant a different type of handling, and that at least one b=0 volume should be acquired at the head. However IMO this is more specific to b=0 volumes and not "the first shell". Indeed in the script in which I invoke dirmerge I don't include the b=0 shell in that call, and manually arrange the b=0 volumes myself afterwards. In that case I was previously getting the first volume as a b=300 volume, when a b=3000 volume would have made more sense. In retrospect I could have just reorder the shells in my invocation; but I nevertheless think that this change is more faithful to how the rest of the command works)

[github-actions[bot]]

clang-tidy review says "All clean, LGTM! :+1:"