Console and `call` craziness on Windows

See also https://github.com/red/red/issues/4262 on Mac bugs

Describe the bug

Simple call

>> call "console"
== 28696

console.exe stays in process list with constant 70% single-core load

---

>> call "gui-console"
== 28948

works totally fine!

---

>> call "red"
== 27280

gui-console-.....exe process can be seen in process list for 2-3 seconds, then it terminates for no apparent reason

---

>> call "cmd"
== 29580

Such PID doesn't exist! Or maybe not long enough to be noticed in task manager (same with call/shell)

---

>> call/output "cmd" %1
== 0

Returns immediately! In the output, some escape sequence trash: ←[92mD:\devel\red\red-src\red←[90m>←[m

Redirected output

>> call/output "console" %1
(does not return until console process is terminated)
== 1

Same high CPU load. The output file contains excessive GC output (it's a debug build): root: 3018/4669, runs: 137, mem: 3362040 => 1642564, mark: 1.0ms, sweep: 1.0ms etc.

---

>> call/output "gui-console" %1
(does not return until gui-console is closed)
== 0

The output file %1 contains all the output except the input prompt and commands typed into it (I typed '123'+Enter):

--== Red 0.6.4 ==--
Type HELP for starting information.

== 123

---

/error behaves same as /output, just the redirected file is empty (as should be)

---

Redirected input

>> call/input "console" %1
(does not return until console process is terminated)
== 1

Stable 100% CPU load by the console process. The input file %1 is locked from even read-only access. Very high RAM usage growth speed (~10MB/sec)
In the terminal (it's a debug build), the output is:

Error Red/System call : write into pipe failed : 6
== 1

---

>> call/input "gui-console" %1
(does not return until gui-console is closed)
== 1

The input file %1 is locked from even read-only access.

Two consoles outputting into the same file

>> call/output "console" %1      ;) twice from 2 different gui-consoles
(waits)
== 0

The file contains output from both consoles, but it's totally messed up - e.g. GC output of one console ends with root: 3018/4669, runs: 40, and then continues with root: 3018/4669, runs: 75,. Apparently consoles lock the file from shared writing but do not preserve the output that were unable to flush in time.

Expected behavior

---

1. Should not load the CPU or eat RAM up.

---

2. Without /wait refinement should:

• if any of (/input, /output, /error) is given a string or binary argument - should return with an error (incompatible arguments - string/binary pipe redirection requires /wait)
• if only file arguments are given to (/input, /output, /error) - should return immediately, with a PID

---

3. /input should not lock the file: the plan was to write/append into it! ;)

---

4. call/wait "cmd" should not terminate immediately IMO, though I've no idea why it does.

---

5. call "red" should not terminate in 2 seconds but show gui console.

---

6. The output file should probably also contain >> ... prompt with commands entered, e.g.:

--== Red 0.6.4 ==--
Type HELP for starting information.

>> 123
== 123

But it's not important.
I just realized issue #4189 could have been auto-testable (for regressions) if console copied the input prompt contents into stdout. Although it's not strictly a guarantee that what it copied is what it actually displayed...

---

7. Lack of shared writing support is a non-issue for me.

---

8. call docstring should clarify that it returns PID without /wait only, and process' return code with /wait (Like, it returned me 100 a few times. What is 100?)

EDIT: 9. Another issue here is that later using this PID is a shot in the dark. It will often work fine. What about the cases where it won't? Quoting SO:

There is an inherent race condition in the use of pid_exists function: by the time the calling program gets to use the answer, the process may have already disappeared, or a new process with the queried id may have been created. I would dare say that any application that uses this function is flawed by design and that optimizing this function is therefore not worth the effort.

At least on Windows - using process handle instead seems to be the reliable way to access the right process.

Platform version (please complete the following information)

Red 0.6.4 for Windows built 27-Dec-2019/1:01:27+03:00