Introduce magic_enum for enum <--> string conversion

[daljit46]

This PR addresses the issue raised in #3264. It adds magic_enum, a C++17 header-only library for enum to string conversions, as a dependency. The changes include the addition of new templated wrapper functions to perform enum <--> string in mrtrix.h. As an initial step (and to limit the scope of this PR), I have replaced several existing string-based usages with enums. These changes are limited to cpp/cmd; no code in cpp/core is affected at this stage, although that could be considered in a future PR.
One issue I encountered is that some existing string values begin with a number. Since C++ identifiers cannot start with a digit, cases such as "2d" and "3d" in mrdegibbs cannot be mapped directly to enum names. Handling these cases would require either custom parsing logic or changes to the CLI options. I have not made any changes for those cases in this PR.

[github-actions]

clang-tidy made some suggestions

[github-actions]

clang-tidy made some suggestions

[github-actions]

clang-tidy made some suggestions

[Lestropie]

Looks nice 👍 Left a few small suggestions.

cases such as "2d" and "3d" in mrdegibbs

Some cases could be dealt with via interface design rather than software engineering. Eg. This functionality could easily be changed from -mode as .type_choice() to -dimensions as .type_integer(2, 4). You didn't happen to keep a list?

[daljit46]

You didn't happen to keep a list?

Going through all the commands, the only other two places where I saw this problem were: peaksconvert.cpp and mtnormalise.cpp.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[Lestropie]

Proposal to change command-line interfaces for better compatibility with magic_enum:

• mrdegibbs: Change -mode from .type_choice({"2d", "3d"}) to -dimensionalityas.type_integer(2, 4). Option is only present on dev, not present in 3.0.x.
• peaksconvert: Very new command that basically nobody other than me knows or cares about. Change options:
  "unitspherical", "spherical", "unit3vector", "3vector"
  to one of:
  "unitspherical", "spherical", "unitthreevector", "threevector"
"unitspherical", "spherical", "uniteuclidean", "euclidean"
  (alternative suggestions welcome)
• mtnormalise: Should be easy to change from .type_choice({"0", "1", "2", "3"}) to .type_integer(0, 4).

Given the list is small, changes are non-intrusive, and it would facilitate making .type_choice() work exclusively on enums, I think we just go ahead with this.

[daljit46]

(alternative suggestions welcome)

How about "unitspherical", "spherical", "unitcartesian", "cartesian"?

[Lestropie]

That's probably what I subconsciously meant, but my conscious somehow landed on the wrong word 😅

[daljit46]

Bikeshedding question: lots of places in the CLI options now use join_enum to convert enum lists to strings. The default separator is a comma with no space in between (e.g. choice1,choice2,choice3). Do we want to add a space?

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[Lestropie]

Somewhat inconsistent across the code base. I'd probably opt for including a space myself: it's intended for human reading, not parsing (anything wanting to parse that information should instead be invoking __print_full_usage__).

[daljit46]

All feedback has been addressed, documentation rebuilt to follow CLI changes and all tests are now passing. This should be ready to be merged.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[Lestropie]

Thoughts on removing
Argument &type_choice(const std::vector<std::string> &c)
in favour of forcing use of
template <typename Enum> Argument &type_choice()?
Personally I would prefer that if there are no contraindicated use cases.

[daljit46]

Yes, that is the end result I would like to see too. From a quick grep, I can see there are still 26 instances of using the old overload of type_choices() . It's obviously possible in principles to replace all those instances with the enum-templated version, but I think we should do so in a future PR. The changes made here are already touching a lot of files and I would prefer to not extend the scope of this PR even further. I think that's best strategy for avoiding introduction of unwarranted issues (despite the trivial nature of the changes here).

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"