demprep completely broken in 10.1.0_RC1

**ISIS version(s) affected**: 10.1.0_RC1

```
wget https://pgda.gsfc.nasa.gov/data/LOLA_20mpp/LDEM_60S_240MPP_ADJ.TIF
gdal_translate -of isis3 LDEM_60S_240MPP_ADJ.TIF LDEM_60S_240MPP_ADJ.CUB -co TARGET_NAME=MOON
editlab from=LDEM_60S_240MPP_ADJ.CUB grpn=Mapping keyw=MinimumLatitude val=-90
fx f1=LDEM_60S_240MPP_ADJ.CUB to=ldem.cub eq="f1+1737400"
demprep from=ldem.cub to=ldemprep.cub
```
In 10.0.0, that works. In 10.1.0_RC1, it throws the following error:
```
**PROGRAMMER ERROR** You can only specify exactly one input or output cube in ProcessByBrick.cpp at 129.
```

(Also, I ran into this while testing TIFF support in demprep, but it looks like it requires a cube with a traditional Mapping group, not an IProj-type one or a GeoTIFF. If this isn't explicit in the documentation, you should add it, and maybe put in a more explicit error message than
`[...snip...] **ERROR** PVL Keyword [LongitudeDirection] does not exist in [Group = Mapping] in PvlContainer.cpp at 68.`)

Reproduce the supplied wget, gdal_translate, editlab, fx, and demprep sequence, then inspect ProcessByBrick.cpp at line 129 and the Mapping-group error path. Done means the 10.1.0_RC1 workflow no longer fails unexpectedly, and the traditional Mapping-group requirement and resulting error are documented or made explicit as appropriate.

Written by the indexing model from the issue text.