[Implementation] Back-deploy CInterop.stat for Migration Compatibility

[jrflat]

This PR back-deploys CInterop.stat(_:_:) and CInterop.Stat to the original CInterop availability to help developer migration in rare cases where FilePath.stat() and FileDescriptor.stat() conflict with existing usage of unqualified stat() in extensions of those types.

See the pitch at: https://forums.swift.org/t/pitch-back-deploy-system-cinterop-stat-for-migration-compatibility/84930
See the full proposal in #298

[rauhul]

I still think this sets a bad precedent for every method we add that enviably shadows a global function.

[jrflat]

I still think this sets a bad precedent for every method we add that enviably shadows a global function.

I agree we should not do this for most, if not all, other methods that shadow a global function. I think stat is a special case for a few reasons:

• Many other syscalls gain a more Swift-y API name, e.g. dup/dup2 -> duplicate(as:), ftruncate -> resize(to:), umask -> FilePermissions.creationMask if that becomes API, etc. Those renames mean user extensions are unlikely to collide with future System API. stat is one of the few syscalls whose C name is already clear and idiomatic enough to use directly as the Swift API name.
• Many syscalls that do keep their C name (e.g. open, close, read, write) have been in System since the beginning, so there was never a window where someone would have needed to roll their own extension for that functionality.
• stat is both widely used and was missing from System for a while, which creates a better chance for migration friction.
• Other syscalls we might add naturally disambiguate through parameter labels. Names like rename, link, and unlink would require non-optional arguments (e.g. rename(to:), link(to:)), so their Swift signatures wouldn't collide with the bare C functions. stat is unusual in that it works as a zero-argument call on FilePath/FileDescriptor and has the same shape for the global C struct stat() initializer.

So I think this CInterop shim more so addresses a specific case and historical gap rather than committing to a pattern we'd need to repeat.

[jrflat]

@swift-ci please test

[rauhul]

is there a way to mark:

public static func stat(_ path: UnsafePointer<CChar>, _ s: inout CInterop.Stat) -> Int32

as externally deprecated to move users off?