read_char: Handle non-tty terminals explicitly

[deadalusai]

Key::Unknown is produced only when:

• A keycode is not recognized by the key_from_key_code function under Windows:

  console/src/windows_term.rs

  Line 337 in b3ecb7d

  _ => Key::Unknown,

• read_key is invoked on a non-tty terminal:

  console/src/term.rs

  Lines 274 to 276 in b3ecb7d

  	if !self.is_tty {
  	Ok(Key::Unknown)
  	} else {

The two places in the code which explicitly handled Key::Unknown were treating it as a proxy for an "unattended terminal" check:

console/src/term.rs

Lines 258 to 263 in b3ecb7d

	Key::Unknown => {
	return Err(io::Error::new(
	io::ErrorKind::NotConnected,
	"Not a terminal",
	))
	}

Since this is only 100% valid to do when running under *nix I've replaced these handlers with an explicit !self.is_tty check instead, which is a common pattern in the Term code. Key::Unknown is now assumed to represent an unprintable / control key and skipped when being evaluated.

I found this issue when pressing the Ctrl key while using the read_key function, which causes it to return Err(Not a terminal) under Windows (but works fine on Linux). In this case, I was in the process of pressing Ctrl + C in order to terminate the program.
It looks like this issue also occurred previously for the Shift and Alt keys under Windows - rather than extend the Keys enum further to support the Ctrl key I think the proposed fix is a little more future proof (though you may like to add support for VK_CONTROL for the sake of completeness anyway).

• [Windows] Not a terminal error when shift key is pressed #83
• Text input yields Key::Unknown on windows_term using alt  #102

[deadalusai]

Related PR on dialoguer: console-rs/dialoguer#192

[ejpcmac]

Pressing AltGr also triggers this behaviour on Windows, which can be more preblematic to enter special characters.