If the user specifies --mporder within -eddy_options, this will be handled in one of two ways:
- If the user has also specified --slspec within -eddy_options, then dwipreproc will find that file, copy it into the temporary directory, and modify the contents of -eddy_options to reflect the location of that file.
If --slspec is not specified within -eddy_options, then dwipreproc will look for 'SliceTiming' within the input DWI header key-value entries. If this is found, then an appropriate slspec file is generated based on the slice timings, and this is provided to eddy.
Closes #1169.

- When importing from DICOM, fill field 'SliceEncodingDirection', which is defined as part of BIDS.
- Whenever MRtrix3 performs a permutation of image axes (whether implicit or explicit), additionally adjust this field, just as is performed for DW and PE schemes.
- If attempting to run dwipreproc with slice-to-volume correction in eddy, ensure that if the slice encoding direction is specified, it corresponds to the third axis (which is what eddy will assume). Permutation of axes as part of dwipreproc may be addressed at a later date.

- dwipreproc: If slice encoding direction is negative, then the information contained in SliceTiming needs to be reversed.
- mrdegibbs: If SliceEncodingDirection is defined in the image header, use that information as appropriate: If the user has not manually specified the within-slice axes, make use of this header information, issuing a terminal message as appropriate; if user provides -axes option, compare to header information and issue warning if they are not consistent.
- Better handling of slice encoding direction in backend. This parameter is in fact permitted to indicate a negative direction (as can be done with PhaseEncodingDirection), and hence axis flips need to be taken into account.
Closes #1173.

Combining changes related to -se_epi option, and those for compatibility with -eddy_options "--mporder", resulted in a couple of little mistakes.

If the number of slices in an axis of the image is odd, and topup is being used, then dwipreproc will duplicate the final slice along that axis, in order to prevent a fatal crash in topup.
However, if slice-to-volume correction is being used, and there are an odd number of slices, then this padding will result in a mismatch between the number of slices in the image data and the number of entries in the slice timing data.
These changes compensate for this by correspondingly altering the slice timing information, and delaying writing that information to file until after image padding has taken place.

- Don't attempt to erase header key-value entries that will never be there due to NIfTI conversion; will just produce unwarranted warnings.
- Disable pylint testing the number of lines in the file (dwipreproc is now close to 1000 lines).