boot: Use correct handle to find TextInputEx protocol

LibLocateProtocol will return the protocol for the first device that
supports it. But it may not actually come from the ConIn device that
we want to use here.

This should be the root cause of what was previously considered just
broken firmware. If you ask the wrong device to return some key, of
course it will never provide one.

This changes the way we handle input yet again in light of this new
knowledge and because using the correct TextInputEx with fallback to
ConIn can actually create double input in some cases.

Since we are now confident that we get the right TextInputEx, we can
use that exclusively, only falling back to ConIn if the console input
device does not support the better interface (the spec is pretty clear
that it must support it, though).

Because some firmware is broken, we still need to provide a fallback
to the previously used TextInputEx thats overrides ConIn/ConInEx if
it is functional.