tidy-up: process.h detection and use

This patch aims to cleanup the use of `process.h` header and the macro
`HAVE_PROCESS_H` associated with it.

- `process.h` is always available on Windows. In curl, it is required
  only for `_beginthreadex()` in `lib/curl_threads.c`.

- `process.h` is also available in MS-DOS. In curl, its only use was in
  `lib/smb.c` for `getpid()`. But `getpid()` is in fact declared by
  `unistd.h`, which is always enabled via `lib/config-dos.h`. So the
  header is not necessary.

- `HAVE_PROCESS_H` was detected by CMake, forced to 1 on Windows and
  left to real detection for other platforms.
  It was also set to always-on in `lib/config-win32.h` and
  `lib/config-dos.h`.
  In autotools builds, there was no detection and the macro was never
  set.

Based on these observations, in this patch we:

- Rework Windows `getpid` logic in `lib/smb.c` to always use the
  equivalent direct Win32 API function `GetCurrentProcessId()`, as we
  already did for Windows UWP apps. This makes `process.h` unnecessary
  here on Windows.

- Stop #including `process.h` into files where it was not necessary.
  This is everywhere, except `lib/curl_threads.c`.

  > Strangely enough, `lib/curl_threads.c` compiled fine with autotools
  > because `process.h` is also indirecty included via `unistd.h`. This
  > might have been broken in autotools MSVC builds, where the latter
  > header is missing.

- Delete all remaining `HAVE_PROCESS_H` feature guards, for they were
  unnecessary.

- Delete `HAVE_PROCESS_H` detection from CMake and predefined values
  from `lib/config-*.h` headers.

Reviewed-by: Jay Satiro
Closes #9703

1 files changed, 0 insertions, 4 deletions

diff --git a/lib/asyn-ares.c b/lib/asyn-ares.c
index 33edba139..993222b83 100644
--- a/lib/asyn-ares.c
+++ b/lib/asyn-ares.c
@@ -47,10 +47,6 @@
 #include <inet.h>
 #endif
 
-#ifdef HAVE_PROCESS_H
-#include <process.h>
-#endif
-
 #if (defined(NETWARE) && defined(__NOVELL_LIBC__))
 #undef in_addr_t
 #define in_addr_t unsigned long