GCC 5.4 does not like using `XferMode::${something}` as there is also
the `XferMode` function visible at the same time.

This commit moves the state from `XFER_GLOBALS` to the context
object.  Some global variables still remain, for example the lists
managed by sll.h and `theXIAddData` from cmds.cc.

The casts are necessary as the structs cannot be defined in the `xfer`
module as long as it is still dim-dependent (same as for the previous
change to the `join` module).

Sorting the forward list of messages means a new first item is chosen,
however the loop to free all XFERMSG objects in DDD_XferEnd will start
from the old list head and no longer frees all entries.  This was not
noticed before the previous commit as the free in DDD_XferEnd was a
no-op and memory would be released by the heap structure instead.

Alternatively one could return the new list head (or pass in a
modifiable reference), but this seems more complex then just skipping
the sorting step.  I doubt handling low resource environments in this
way is still necessary.

The casts are necessary as the structs cannot be defined in the `join`
module as long as it is still dim-dependent.

Also convert `JoinMode` to a scoped enumeration type.

If `LoopProc` fails, it should probably just throw an exception.

This silences several compiler warnings about `error` not being used.

Use `new` and `delete` instead of `AllocCom` (`FreeCom`) as allocators
from the dimension-dependent can no longer be used.

The counters might be used by the various initialization functions and
therefore have to be set to zero earlier.

This worked previously as variables with static storage duration are
zero-initialized and DDD left them at zero when exiting as well.
However the context object's member variable is not zero-initialized
so this broke with the change as at least `nCplItems` was used by
`ddd_IFInit`.