Bump up to 0.2.76

Let's prevent this from happening again.

libc 0.2.75

Skip test on aarch64 due to https://github.com/rust-lang/libc/issues/1765

PSP: A few corrections to types and function signatures

Add ucontext_t for aarch64-unknown-linux-musl

Move `x86_64-unknown-cloudabi` to tier 3 check

Linux defines a waitid type `P_PIDFD`, for use with process file
descriptors (`pidfd`). Add that constant.

In libc-test, add linux/wait.h to the Linux-specific and
Android-specific headers, to get the definition. Exclude it on Android
and musl for now, though, as the versions in CI don't have it yet.

Add execl* functions on Windows

Expose si_pid and si_uid from siginfo_t as functions

Add CLD_ constants

On Linux, `sys/wait.h` defines a `W_STOPCODE` macro to construct a stop
code from the signal number of a stopping signal. Provide an equivalent
function.

Suggested-by: Ivan Tham <pickfire@riseup.net>

The SIGCHLD variant of the siginfo structure also provides fields for
user and system time; expose those as well.

The first 3 fields of `siginfo_t` have different orders on MIPS. When
casting `siginfo_t` to a different type to access the fields of the
`sifields` union, avoid giving names to the first three fields, since
they're only present for memory layout and shouldn't be accessed from
the casted structure type.

 Add mac/ios pthread_from_mach_thread_np

On Linux, siginfo_t cannot expose these fields directly due to
https://github.com/rust-lang/libc/issues/716 , so expose them as
functions, just like si_addr and si_value.

In order to get alignment correct on both 32-bit and 64-bit
architectures, define an sifields union that includes a pointer field,
to ensure that it has the same alignment as a pointer.

These constants appear in the si_code field of a SIGCHLD signal or
waitid-returned siginfo value.

On Linux, `sys/wait.h` defines a `W_EXITCODE` macro to construct an exit
code from a return value and a signal number. Provide an equivalent
function.

Allows us to get a pthread id from a match thread id.
From pthread.h [1]:

```
__API_AVAILABLE(macos(10.5), ios(2.0))
_Nullable pthread_t pthread_from_mach_thread_np(mach_port_t);
```

[1] - https://opensource.apple.com/source/libpthread/libpthread-416.40.3/pthread/pthread.h.auto.html

add openpty and forkpty implementation for illumos systems

At time of writing, illumos systems do not provide an implementation of
the openpty() and forkpty() wrappers provided on some other UNIX
systems.  While we expect to grow an implementation, it seems prudent to
provide a compatibility routine here first to unblock illumos support in
the popular nix crate.

DevkitPPC does not support unix sockets natively, meaning that bindings
to these functions was removed for powerpc targets with "nintendo" as
vendor.

Suggested target json files:

Nintendo Gamecube:
```
{
  "arch": "powerpc",
  "data-layout": "E-m:e-p:32:32-i64:64-n32",
  "dynamic-linking": false,
  "env": "newlib",
  "executables": true,
  "has-elf-tls": false,
  "has-rpath": true,
  "linker-flavor": "gcc",
  "llvm-target": "powerpc-eabi",
  "max-atomic-width": 32,
  "os": "dolphin",
  "target-c-int-width": "32",
  "target-endian": "big",
  "target-family": "unix",
  "target-mcount": "_mcount",
  "target-pointer-width": "32",
  "vendor": "nintendo"
}
```

Nintendo Wii:
```
{
  "arch": "powerpc",
  "data-layout": "E-m:e-p:32:32-i64:64-n32",
  "dynamic-linking": false,
  "env": "newlib",
  "executables": true,
  "has-elf-tls": false,
  "has-rpath": true,
  "linker-flavor": "gcc",
  "llvm-target": "powerpc-eabi",
  "max-atomic-width": 32,
  "os": "revolution",
  "target-c-int-width": "32",
  "target-endian": "big",
  "target-family": "unix",
  "target-mcount": "_mcount",
  "target-pointer-width": "32",
  "vendor": "nintendo"
}
```

Add more constants for getnameinfo on android