realtime: resolve: do not mess improperly with tr_backwards

realtime: resolve: do not mess improperly with tr_backwards

Previously we would attempt to sort out Segment.tr_backwards in
resmain_getmovpos.  This is wrong because *_getmovpos shouldn't have
that kind of side-effect.

Furthermore the actual code was wrong: it wasn't idempotent: the
number of times tr_backwards would be inverted for a backwards train
would depend on how many times resmain_getmovpos was called.

Actually, for backwards trains not resolving at home, there is no need
to mess with tr_backwards.  The existing tr_backwards for the segments
it owns is fine.  For trains resolving at home, we need to explicitly
clear the train's direction too, and we should do this in a dedicated
piece of code.

Fixes:
@2011-01-10 20:28:23 GMT info save-dump +dump.2011-01-10T20-28-23+0000
	traversed santafe forwards from B8 to B7 when B7/J1