Following on from #591, and something that has come up during the process of #725.

Providing an automated processing pipeline where you don't necessarily know a priori what type of reversed phase-encode acquisition has taken place, or what direction(s) the phase encoding directions are in, or whether a fieldmap has instead been acquired. In such cases the current dwipreproc interface is limited.

I've started on code to extract the phase encode direction and readout bandwidth information from DICOMs; and this information is expected to be provided in BIDS compliant data. But given the number of possible combinations of such data, it may be preferable to instead embed this information within image headers, so that dwipreproc can figure out what it has to do (this would be in addition to the current 'manual' options for specifying phase-encoding information).

One option would be to embrace the approach in #591, adopting a wider 'standard' of having phase encoding information embedded within the 'dw_scheme' header entry. Alternatively, particularly since the DWI scheme is now a plain key/value entry in the header rather than a dedicated field, we could add a 'pe_scheme' entry. I think I'm in favour of the latter; not only for separating the two sources of information, but also the DW scheme is specified with respect to scanner space whereas the PE scheme is with respect to image axes, so combining them is a bit of a hack.

There's a semi-standardised header field '"PhaseEncodingDirection' (i, i-, j, j-, k, k-) that may be specified for any particular image file, but obviously this can't vary for different volumes in a 4D image. I could technically get away with just using this information, but it would require a lot of gymnastics in order to figure out how to invoke dwipreproc, and wouldn't be guaranteed to work for all cases. Plus, given whatever evil scheme @jdtournier has going that spawned #591 requires a PE direction per volume, I reckon it looks like a good idea to support that longer-term.

Opening up for discussion / comments. If I go for my preferred option ('PhaseEncodingDirection' for fixed PE direction, 'pe_scheme' for variable), @jdtournier you'll need to warp your code around that accordingly.