Add client, server and experiment latency status lights overlay to video feed

[timdrysdale]

To support DIY users whilst maintaining the reputation of the code for real-time latency where supported by network connections, we should provide diagnostic information by default, then server providers and users can see where any latency issues are arising, and consider how they might address them if necessary/appropriate - for some experiments that are slow to respond anyway like x-ray diffractometer it wouldn't need addressing, and for those users that have slow connections through digital poverty, we should be careful to avoid providing a value judgement on the available connection.

For example we might consider a round trip time (RTT) from user interface to experiment and back again to have the following categories

(a) excellent - blue - RTT <=120ms
(b) acceptable - green - RTT <=250ms
(c) tolerable - orange - RTT <= 500ms
(d) delayed - red - TDD > 500ms

Brodnevs, Deniss & Kutins, Aleksandrs. (2021). Requirements of End-to-End Delays in Remote Control Channel for Remotely Piloted Aerial Systems. IEEE Aerospace and Electronic Systems Magazine. 36. 18-27. 10.1109/MAES.2020.3039853.

We could measure the RTT from experiment to server, and from server to client, but we may also consider measuring the RTT from another location(s) to the server to estimate whether the server is on a slow connection, e.g. to our main server database.

We could provide the information to the UI in text form to overlay over the video, in a standard video widget that we expect many would implement, so that it can be manipulated in terms of presence/size/location to suit the user interface.

Or we could provide the information to the experiment's video streaming service, to overlay at source (Where ffmpeg is already running so the overlay is efficient)

It would not be efficient to decode, overlay and re-encode at the server.