Inconsistency with _dup2 on Windows

[jakepetroules]

On Windows, _dup2 is documented to return 0 to indicate success, in contrast to POSIX's dup2, which returns the new file descriptor.

Should we change the Windows syscall adapter to something like:

@inline(__always)
internal func dup2(_ fd: Int32, _ fd2: Int32) -> Int32 {
  _dup2(fd, fd2)
  return fd2 // dup2 is documented on windows to return 0 on success while POSIX expects fd2, 
             // so always return fd2 for consistency
}

I understand the general spirit of swift-system is to match the platform behavior, but this one stands out as potentially quite surprising, so I wonder if we should at least call it out in the documentation comments for this function?

[glessard]

The current state of FileDescriptor on Windows is that it's become a questionable POSIX-emulation layer, and it shouldn't be this way. We should have the thinnest possible wrappers over the platform calls, with the translation limited to adapting language differences. Cross-platform behaviour should be implemented by swift-foundation.

[jakepetroules]

I think there was probably some misunderstanding here -- this is an internal API call used solely to service the public API we have defined, and the public API fails to fulfill its contract right now, resulting in the file descriptor returned by FileDescriptor.duplicate(as:) always being zero (as opposed to containing the new file descriptor value). The return value is explicitly documented as "The new file descriptor". That is just a bug that we need to fix.