Unsurprisingly, netplay and runahead are wildly incompatible; both rely
on internal rewinding, without communicating this fact to each other.
Somewhat more surprisingly, netplay already has all the infrastructure
for negative input latency, as it's structurally the same as receiving
delayed input from a peer. This patch makes the two features
"compatible" by disabling runahead per se when netplay is active, and
using runahead's configuration to adjust netplay's own input latency
feature, which is now allowed to be negative. The effect is mostly the
same (modulo the second core support), and it doesn't confuse netplay
peers.
Really silly bug had netplay forgetting to unset device availability
when a client goes to spectator mode. As a consequence, in certain
configurations, later joins would automatically choose the wrong device,
and you'd have to manually specify a device to get the right one. This
fixes that.
Netplay sync incorrectly checked whether the replay pointer was behind
the unread pointer twice, when in the second check it should only have
been checking if it was behind the current execution pointer. Because of
how resimulation works with device sharing, I THINK this could affect
sync. Even if it can't, it's wrong.
An unfortunate hack for cores that translate the keyboard input device
into keydown/keyup events without saving that in the savestate. We
simply replay the previous frame's input before loading the rewound
frame's state, to assure that both the state and the keyup/down state
are correct.
Ideally, cores would save this as part of the state, but it's a bit
proximal and a fairly significant change for those that use it, so it's
easier to fix in netplay.
This abstracts away the details of particular input devices for netplay,
and adds support for mice and (similar) lightguns. Unfortunately, in
practice, no core handles mice or lightguns in a savestate-safe way, so
they need to be used in stateless mode to be reliable, but they do work.
(1) All mode change code unified, so server mode changes and client mode
changes and announcements go through the same functions
(2) New messages which are translateable and work with multiple input
devices
The new input handling makes adding and removing players more
complicated, since data can be present that's not expected from the
connected clients list, or absent that's expected in the list but
actually shouldn't be there.
