[regression] ambiguity libc/ffi/os::raw for c_ types

[Mark-Simulacrum]

• https://crater-reports.s3.amazonaws.com/beta-1.61-2/beta-2022-04-18/reg/jimage-0.2.3/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.61-2/beta-2022-04-18/reg/snap7-rs-1.142.0/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.61-2/beta-2022-04-18/reg/jerk-0.2.2/log.txt
• https://crater-reports.s3.amazonaws.com/beta-1.61-2/beta-2022-04-18/reg/tomcrypt-0.1.0/log.txt

Introduced by #94503, most likely, cc @joshtriplett

[petrochenkov]

One reasonable fix is to stabilize these types in std::ffi.
That will allow using use reexports instead of type aliases, which will remove the ambiguities.
They are the same types as stable types in std::os::raw just exposed from a different (but also stable) location in the same crate.

(That said, glob vs glob is an acceptable breakage according to the library policy.)

[joshtriplett]

That would be a fast stabilization, but given that they're rather simple types, that seems potentially reasonable.

[Mark-Simulacrum]

If we were to stabilize, presumably we'd do that on master and back out the PR from beta? I am reluctant to backport a stabilization to fix this (particularly a fast one, as you mention).

[joshtriplett]

@Mark-Simulacrum Yeah, reverting the PR on beta seems fine for now.