Follows from initial comments in #2772.

Use of the median operation in mrmath is currently leading to a memory leak. This is due to construction of an Image<Operation>, where template class Operation could be class Median, which itself must allocate memory dynamically, but that memory is never freed.

Ignoring median for a moment, this is a rare case where template class T for Image<T> is a non-trivial, non-builtin type. I've done this myself in the past using a pointer class for DWI::Fixel_map<>, but it was always a bit of a hack, and I think that if we want Image<> to be able to handle types other than what you'd expect to find in an image on disk, we'd need to be more deliberate about it.

But back to median. I've tried a couple of different approaches---mostly around having the Median class store a pointer to dynamically allocated memory managed elsewhere---but not been able to resolve the leak.

Some possible ways forward:

1. Somebody cleverer than me finds a simple fix.
2. Make the requisite modifications to template class Image such that if the template type is non-trivial, the destructor for each voxel is called.
   Not a huge fan.
3. Modify mrmath so as to not store an Image of Operations.
   What I envisage instead is something that:
   • Inherits from Image<float> and provides the requisite interface for looping
   • Internally constructs an MR::Voxel2Vector to allocate a unique index to each output image voxel
   • Internally allocates a std::vector<Operation> to perform the calculations for each voxel
   • Writes the final calculations to the output image upon completion

In the absence of 1, 3 is a bit of work, so seeking comment before proceeding.