The 0xfa code can be a key scancode or it can be a protocol scancode.

Only few keyboards use it as a key scancode, and if we always interpret
it as a protocol scancode then these rare keyboards will have a dead
key.  If we interpret it as a key scancode then we have a dead keyboard
in case it was protocol.

Clearly it is safer to prefer to interpret it as a protocol scancode.

This moves the test for ACK and NAK up, so that they are always seen as
protocol.

This is just a minimal patch.  What I did in 1.1.54 was to keep track of
commands sent with a flag reply_expected, so that 0xfa could be taken as
ACK when a reply is expected and as key scancode otherwise.  That is the
better solution, but requires larger surgery.