Blocking commands prevent Estop on USB channel

[AndyEveritt]

Sending a command such as G32 will prevent an estop (M112 M999) from being processed when they are sent via USB.

This is needed for DuetScreen to function as expected

[T3P3]

will be solavble in 3.7 by using the second USB channel. might consider a change for 3.6.3 that does not require the second channel.

[dc42]

Possible change to 3.6:

1. Create a new subclass of GCodeInput, based on the existing one used by USB channels (RegularCodeInput?), that overrides the FillBuffer function.
2. In that FillBuffer function, at the end check the data that has been read for instances of the out-of-band code that we use to signal emergency stop. Need to allow for the possibility of that code being received split over two calls to FillBuffer (so we need to record if the last character in a call was the first character of the signal). If the special code is found, execute an emergency stop. We may need to defer this to another point in the code - see how the async serial class does it.
3. Call that FillBuffer function not only where we currently do but also in the GCodes main loop, for USB buffers only.
   Need to make sure we don't significantly slow down the USB throughput (i.e. the rate at which we process incoming GCode commands).