TORCS: tried to fix automatic transmission thrashing.

Now we have a GearUp and GearDown action and syncA looks different.

For some reason the client still gets out of sync. The SimpleDriver
doesn't. Currently trying forkOS instead of forkIO, but that doesn't
help much either. Removing the threadDelay helps a bit, but there are
still some timeouts.
TORCS: changed inter-thread communication a bit.

1. CarState is now stored in a MSampleVar instead of IORef + Sem.
   It is only written in the Driver's command loop, and read (and thus
   emptied) only by the Perception BAT's syncA function.
   For this use-case, MSampleVar is exactly what we want: the writer
   can always write (if the MSampleVar is full already, its content
   is replaced), but the reader blocks until something is available.
   This doesn't block Driver's command loop, but it does block the
   Perception BAT until there's something to perceive.
   (The previous solution with IORef + Sem was equivalent.)
2. The visualization has its own access channel to the top-level
   situation (currently from the WarmUp BAT) through an MSampleVar.
   Same arguments as in case 1.
3. CarControl is only stored in a single IORef, which is written by both
   the Gear and Transmission BATs using atomicModifyIORef'. Since
   according to some Stackoverflow post readIORef is atomic, too, so
   there are no race conditions.
   The Driver's command loop isn't blocked, and the producing BATs
   can write whenever they want to. That's what we want in this case.

Finally it seems like in this scenario the timeouts of the SCR server
aren't bad for us, at least under the assumption that the Driver's
command loop has enough CPU time. In this case there is only one
blocking operation: reading new CarStates from the SCR server. It then
posts the received CarState to the MSampleVar (non-blocking), reads the
latest CarControl from the IORef (non-blocking), and sends the result
back to the SCR server.
If this loop takes too long, the CarControl is discarded. But if the
command loop is not constantly too slow, it will make up for the lost
time, receive the accumulated CarStates and respond to each with the
current CarControl.