Track train ratio correctly again

I realized that I made an obvious mistake at some point when simplifying the train ratio tracker - making it in some cases get stuck at 10%. That is obviously not great, so let's fix it. At the same time, I'd like to avoid the ramp-up from 0 on device startup and maybe make a better estimate in general.

Some details about the old version: had upper limit on buffer size (how many train IDs to remember) and the maximum span between oldest and newest train in buffer. The idea being that if the buffer is full of old trains, there's a long break, and we start getting data, then quickly evicting the old train IDs would give a fairer estimate for resumed data stream. Or something like that - not very well thought out.

New version never evicts, just fills up buffer. But if device goes from PROCESSING to ON, it can just reset the tracker. Also, it now queries the train ratio tracker based on timeserver current train ID, so if data stops entirely, train ratio will start dropping as one would expect (like the rate tracker). The previous version did sort of support this, I just didn't use it - it only updated its value on input.

Bonus: to avoid time of flight from detector causing the train ratio to get stuck at just below 100 % for full data (which comparing to "current train ID" could easily cause), I added a running estimate of input delay and tell the ratio tracker to allow twice this delay before it starts considering a train missing. Could be more sophisticated, feel free to repaint the bikeshed.