MdeModulePkg/UsbKb: fix shell edit cannot read '!@#$%^&*' characters

MdeModulePkg/UsbKb: fix shell edit cannot read '!@#$%^&*' characters

Commit 5563281fa2b31093a1cbd415553b9264c5136e89
* ShellPkg/[hex]edit: use SimpleTextInEx to read console
changes shell edit and hexedit to read input through SimpleTextInEx.

It exposes a issue in UsbKeyboard driver:
Per UEFI Spec,
When interpreting the data from this function (ReadKeyStrokeEx), it
should be noted that if a class of printable characters that are
normally adjusted by shift modifiers (e.g. Shift Key + "f" key) would
be presented solely as a KeyData.Key.UnicodeChar without the
associated shift state. So in the previous example of a Shift Key +
"f" key being pressed, the only pertinent data returned would be
KeyData.Key.UnicodeChar with the value of "F".

UsbKeyboard driver does convert Shift Key + "f" to "F" without the
shift state. But it doesn't do the conversion for all printable
characters, e.g.: Shift Key + "1" --> "!".

The root cause is today's logic to check whether a character is
printable or not is as below:
  if ((KeyDescriptor->AffectedAttribute & EFI_AFFECTED_BY_CAPS_LOCK)
      != 0) {

So it only converts Shift + "a"-"z", but doesn't for Shift + "0"-"9",
and Shift + "["...

The patch updates the check logic as below to fix the issue:
  if ((KeyDescriptor->Unicode != CHAR_NULL) &&
      (KeyDescriptor->ShiftedUnicode != CHAR_NULL) &&
      (KeyDescriptor->Unicode != KeyDescriptor->ShiftedUnicode)) {

The above check is TRUE when the character is printable and
it's *really* affected by Shift key.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>