Cygwin: processes: use dedicated Cygwin PID rather than Windows PID

Cygwin: processes: use dedicated Cygwin PID rather than Windows PID

Using the Windows PID as Cygwin PID has a few drawbacks:

- the PIDs on Windows get reused quickly.  Some POSIX applications choke
  on that, so we need extra code to avoid too quick PID reuse.

- The code to avoid PID reuse keeps parent process handles and
  (depending on a build option) child processes open unnecessarily.

- After an execve, the process has a split personality:  Its Windows PID
  is a new PID, while its Cygwin PID is the PID of the execve caller
  process.  This requires to keep two procinfo shared sections open, the
  second just to redirect process info requests to the first, correct
  one.

This patch changes the way Cygwin PIDs are generated:

- Cygwin PIDs are generated independently of the Windows PID, in a way
  expected by POSIX processes.  The PIDs are created incrementally in
  the range between 2 and 65535, round-robin.

- On startup of the first Cygwin process, choose a semi-random start PID
  for the first process in the lower PID range to make the PIDs slightly
  unpredictable.  This may not be necessary but it seems kind of inviting
  to know that the first Cygwin process always starts with PID 2.

- Every process not only creates the shared procinfo section, but also a
  symlink in the NT namespace, symlinking the Windows PID to the Cygwin
  PID.  This drops the need for the extra procinfo section after execve.

- Don't keep other process handles around unnecessarily.

- Simplify the code creating/opening the shared procinfo section and
  make a clear distinction between interfaces getting a Cygwin PID and
  interfaces getting a Windows PID.

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>