Properly implement WaitForData for ReadConsoleInput

[lhecker]

There were two bugs:

• Ever since the conhost v1 -> v2 rewrite the readDataDirect.cpp
  implementation incorrectly passed false as the wait flag.
  The unintentional mistake is obvious in hindsight as the
  check for CONSOLE_STATUS_WAIT makes no sense in this case.
• The ConPTY integration into InputBuffer was done incorrectly,
  as it would unconditionally wake up the readers/waiters without
  checking if the buffer is now actually non-empty.

Closes #15859

Validation Steps Performed

Test code:

#include <Windows.h>
#include <stdio.h>

int main() {
    HANDLE in = GetStdHandle(STD_INPUT_HANDLE);
    INPUT_RECORD buf[128];
    DWORD read;

    SetConsoleMode(
        in,
        ENABLE_PROCESSED_INPUT | ENABLE_VIRTUAL_TERMINAL_INPUT
    );

    for (int i = 0; ReadConsoleInputW(in, buf, 128, &read); ++i) {
        printf("%d read=%lu\n", i, read);
    }

    return 0;
}

Run it under Windows Terminal and type any input. >50% of all
inputs will result in read=0. This is fixed after this PR.

[lhecker]

Much cleaner and safer. Also, it's more correct. We would previously call WakeUpReadersWaitingForData unconditionally but the storage could still be empty. This error has probably been in conhost since v1.

[lhecker]

The second fix. It's also redundant with _writeString, especially with _vtInputShouldSuppress kicked out.

[lhecker]

The first fix.

[lhecker]

Makes no sense IMO to check this here if we can just pass down fIsWaitAllowed and avoid a waiter from being created in the first place.

[carlos-zamora]

(Double checking) intentional?

[lhecker]

Huh, I was certain I reverted this...

[carlos-zamora]

nit: update the function comment above

[carlos-zamora]

nit: setWaitEvent is still documented above. It should be removed.