[FR] Support out of order execution

Nobody has claimed this yet.

I have just added this feature to Repetier-Server 0.94.4 beta. You can already download it for testing (linux versions only). Also implemented it into Repetier-Firmware 2 so I could do a full test. Main reason was a problem with emergency parser and host prompt support I had when implementing it into server. When I simulated a filament change and selected purge more often enough the firmware stopped responding due to full input buffer from all emergency commands. Other dialogs can also get that problem. Problem is that input buffer does not get cleared until executed, but here communication in general is stopped so it will not happen. So with this small protocol change that needs active activation from host side this would be easy to solve. Maybe more easily in repetier-firmware due to the way we handle emergency parsing, but I think it still would be possible also in marlin.

My notes on implementation (same as described on reprap https://reprap.org/wiki/Firmware_Capabilities_Protocol#Cap:OUT_OF_ORDER :

Currently all commands are parsed in order with the exception of some emergency commands. These are
executed as fast as they get detected. The problem is that they stay in queue until they get handled
in correct order to provide the "ok" for host in right order to not confuse host.

Now there are cases where you need to send multiple "emergency" commands like M876 to navigate through
e.g. filament change. When you need to purge several times the buffer is full and firmware
does not react any more on host navigation.

There are also commands where it would be nice if they work out of order as well because we do
not want to wait like babystepping or which are just informational and do not need to be executed
in order like M105. Imagine being able to send M115 during slow homing and get updates.

So this is where this extension kicks in. It is designed to be fully backwards compatible
to existing hosts. The idea is to have a list of codes that can be executed out of order.
These commands get removed from input queue once executed and hence free the input buffer.

Sequence is as follows.

1. Report in M115 the capability for out of order execution:
Cap:OUT_OF_ORDER:1

2. Wait for host to confirm it understands the extension and send supported codes:
M576 S1
out_of_order:M108 M112 M290 M876

Mark feature enabled for the serial where we got the command from. For multiple connections not all might support it.
Host now has a list of all codes that are handled out of order. That way the list can be extended any
time without requiring host changes!

3. When a out of order commands on supported connection execute it and confirm it:
ooo M290

Out of order commands should have no line numbers. That would make problems with the sequential line
numbering of regular commands. With the "ooo" instead of "ok" host knows the emergency buffer is
freed and it is safe to send next out of order command.

Race case:
When a connect does not reset the connection the firmware might have out of order
enabled while the connecting host does not have it enabled and expects an "ok" instead
of "ooo" response. To help solve the issue a call of M115 should disable out of order
automatically until host reenables it on seeing the OUT_OF_ORDER capability. As long
as host sends M115 before any out of order commands this will solve the race condition.

Start by reading the existing M115 capability response, M576 handling, and emergency-command parsing paths, then compare them with the referenced RepRap OUT_OF_ORDER protocol. Trace how serial connections queue and acknowledge commands. Done means the negotiated capability, supported-code list, per-connection activation, and `ooo` responses behave as described without breaking regular command ordering.

Written by the indexing model from the issue text.