Clang tidy autofix

[Lestropie]

Downstream of #3368.

Draft PR for now; I plan to at some point review individual commits myself before asking for feedback, but it's not a high priority right now, I just wanted it committed and lodged to flush it from my in-progress task list.

---

As first exemplified in #2829, clang-tidy has the capability---for some of its checks at least---to automatically apply the prescribed correction corresponding to the issue detected. In my limited experience it can be a bit hit-and-miss as to whether it gets things right or not. But combined with generative AI to clean up any compilation errors, it's potentially quite powerful for not a whole lot of human time investment.

#3368 introduced the capability to split clang-tidy detection capabilities between what is merely reported in an auto-generated PR review (which we've had running for a little while now), and enforcement of certain checks in PR content (which should ideally be enforced across the whole code base before commencing enforcement on PR content).

What I've done here is interrogated which clang-tidy checks both have the autofix capability, and would potentially yield improvement to code quality / mitigation of bugs. These were run in rank order, re-establishing compilation each time, and also adding that specific check to the enforcement clang-tidy CI check. These all ran through with pretty minimal time investment on my part (thus far; code review is obviously a different question, though passing all C++ tests should give some confidence).

Edit: Manual review completed.

[Lestropie]

This work should I think be done. There are however outstanding questions to be posed to @MRtrix3/mrtrix3-devs:

1. Adoption vs. enforcement.
   For some checks, it's quite possible that while modifying the existing code base through automated means is a net benefit, enforcement of those same checks upon devs and external contributors alike might be considered excessive. So the code changes could be preserved but the checks removed from the enforcement configuration file (which now does pre-commit hook as well as CI).

2. Set of checks.
   Are there any modifications here that any devs outright disagree with and would prefer to be omitted from the changeset? Or knowledge & preference for one that I've not yet included here?

The ones I'd highlight as possible to receive exception:

1. @jdtournier seems to like implicit bool conversions. However I'm increasingly disliking them. Makes it impossible to tell from a conditional statement what is intrinsically a bool. And it's bug-prone; this check is what exposed Fix image gradients w.r.t. scanner for non-1mm & anisotropic voxels #3392, which has potentially been detrimental to non-linear registration performance from the outset.

2. The auto check I don't always agree with. I would typically only use it for very long and/or complex type names. However the determining factor for clang-tidy is whether the type can be inferred from the statement. Which means that if one does e.g. static_cast<size_t>(std::round(value)), it will insist on using auto.

3. [[nodiscard]] can take up quite a bit of space when navigating library headers. It is however a bug detection tool, which makes it hard to exclude. FORCE_INLINE is similarly distracting in some header files and is probably no longer needed (or indeed detrimental)...

4. The readability-isolate-declaration check I added late. I definitely get caught out at times missing subtle multi-declarations; and sometimes one will have a default initialisation and the other won't, which becomes difficult to spot. It feels counter-intuitive to enforce a column line width limit for readability and side-by-side comparison, but then obfuscate declarations mid-line. I've started writing all code like this some time ago I think.