autotools: reduce brute-force when detecting recv/send arg list

autotools: reduce brute-force when detecting recv/send arg list

autotools uses brute-force to detect `recv`/`send`/`select` argument
lists, by interating through _all_ argument type combinations on each
`./configure` run. This logic exists since
01fa02d0b545e1433dced2430561f8c0c72b74a9 (from 2006) and was a bit later
extended with Windows support.

This results in a worst-case number of compile + link cycles as below:
- `recv`: 96
- `send`: 192
- `select`: 60
Total: 348 (the number of curl C source files is 195, for comparison)

Notice that e.g. curl-for-win autotools builds require two `./configure`
invocations, doubling these numbers.

`recv` on Windows was especially unlucky because `SOCKET` (the correct
choice there) was listed _last_ in one of the outer trial loops. This
resulted in lengthy waits while autotools was trying all invalid
combinations first, wasting cycles, disk writes and slowing down
iteration.

This patch reduces the amount of idle work by reordering the tests in
a way to succeed first on a well-known platform such as Windows, and
also on non-Windows by testing for POSIX prototypes first, on the
assumption that these are the most likely candidates these days. (We do
not touch `select`, where the order was already optimal for these
platforms.)

For non-Windows, this means to try a return value of `ssize_t` first,
then `int`, reordering the buffer argument type to try `void *` first,
then `byte *`, and prefer the `const` flavor with `send`. If we are
here, also stop testing for `SOCKET` type in non-Windows builds.

After the patch, detection on Windows is instantaneous. It should also be
faster on popular platforms such as Linux and BSD-based ones.

If there are known-good variations for other platforms, they can also be
fast-tracked like above, given a way to check for that platform inside
the autotools logic.

Reviewed-by: Daniel Stenberg
Closes #9591