Fix OSX builders on CI

Looks like Travis has moved on from our old images, so we're forced to
update.

Add the FIO* consts for *-apple-*

Previously only FIONREAD was implemented for x86_64 apple. The constant is shared between i{3..6}86 and x86_64, so I've moved it into the shared module rather than the 64 bit specific one.

They're defined like this in sys/filio.h:
```
#define FIOCLEX	     _IO('f', 1)        /* set close on exec on fd */
#define FIONCLEX     _IO('f', 2)        /* remove close on exec */
#define FIONREAD    _IOR('f', 127, int) /* get # bytes to read */
#define FIONBIO     _IOW('f', 126, int) /* set/clear non-blocking i/o */
#define FIOASYNC    _IOW('f', 125, int) /* set/clear async i/o */
#define FIOSETOWN   _IOW('f', 124, int) /* set owner */
#define FIOGETOWN   _IOR('f', 123, int) /* get owner */
#define FIODTYPE    _IOR('f', 122, int) /* get d_type */
```

Rather than decipher the C macros I got the values like so:
```
#include <stdio.h>
#include <sys/ioctl.h>

int main() {
	printf("pub const FIOCLEX: ::c_uint = 0x%x;\n", FIOCLEX);
	printf("pub const FIONCLEX: ::c_uint = 0x%x;\n", FIONCLEX);
	printf("pub const FIONREAD: ::c_ulong = 0x%lx;\n", FIONREAD);
	printf("pub const FIONBIO: ::c_ulong = 0x%lx;\n", FIONBIO);
	printf("pub const FIOASYNC: ::c_ulong = 0x%lx;\n", FIOASYNC);
	printf("pub const FIOSETOWN: ::c_ulong = 0x%lx;\n", FIOSETOWN);
	printf("pub const FIOGETOWN: ::c_ulong = 0x%lx;\n", FIOGETOWN);
	printf("pub const FIODTYPE: ::c_ulong = 0x%lx;\n", FIODTYPE);
}

$ gcc --target=i686-apple-darwin -o x x.c && file ./x && ./x
./x: Mach-O executable i386
pub const FIOCLEX: ::c_uint = 0x20006601;
pub const FIONCLEX: ::c_uint = 0x20006602;
pub const FIONREAD: ::c_ulong = 0x4004667f;
pub const FIONBIO: ::c_ulong = 0x8004667e;
pub const FIOASYNC: ::c_ulong = 0x8004667d;
pub const FIOSETOWN: ::c_ulong = 0x8004667c;
pub const FIOGETOWN: ::c_ulong = 0x4004667b;
pub const FIODTYPE: ::c_ulong = 0x4004667a;

$ gcc --target=x86_64-apple-darwin -o x x.c && file ./x && ./x
./x: Mach-O 64-bit executable x86_64
pub const FIOCLEX: ::c_uint = 0x20006601;
pub const FIONCLEX: ::c_uint = 0x20006602;
pub const FIONREAD: ::c_ulong = 0x4004667f;
pub const FIONBIO: ::c_ulong = 0x8004667e;
pub const FIOASYNC: ::c_ulong = 0x8004667d;
pub const FIOSETOWN: ::c_ulong = 0x8004667c;
pub const FIOGETOWN: ::c_ulong = 0x4004667b;
pub const FIODTYPE: ::c_ulong = 0x4004667a;
```

I'm just awaiting an XCode install to check they're the same on arm.

Add alignment feature and use #[repr(align(x))]

Trying to solve #1042.

Here I introduce the discussed feature that will allow going from struct alignment with a private `__align` field to using `#[repr(align(x))]`. However, I have not implemented it for all structs that require alignment yet, only `in6_addr`. This because I did not want to spend too much time before we have discussed and solved the remaining questions regarding this.

One thing to discuss is testing. I have so far not done anything to the CI scripts. So currently they will still test the crate only with the `align` feature disabled. Thus they will make sure the `__align` fields are still correct. But no automatic tests make sure everything is correct when the `align` feature is turned on. What do we want to do about that? Can we insert another `cargo test` with `--features align` to make all the Travis jobs run the test suite twice, or will that slow things down too much?

I have tried using this version of libc in rustc and the standard library. And successfully changed `Ipv6Addr::new` to not use any `unsafe` and to become a `const fn`. Whether or not we want that is out of scope for this PR, but my point was that the changes introduced with this PR allow much more flexible usage of the libc structs that have alignment.

Add some posix_spawn apple extension flags

Revert "Link to libgcc when statically linking musl"

This causes linker errors due to duplicated symbols. See https://github.com/rust-lang/rust/pull/52157

This reverts commit 920cfeac.

Add MODULE_INIT_ constants

These are flags required to implement the linux kernel loading mechanism.
Specifically finit_module.

These are flags required to implement the linux kernel loading mechanism.
Specifically finit_module.

Implement statfs for dragonfly, freebsd and openbsd

Openbsd fix

put in several fixes for OpenBSD (one fix per commit).
testsuite ran on OpenBSD 6.3-current (upcoming 6.4)

```
RUNNING ALL TESTS
PASSED 6474 tests
```

they doesn't exists on OpenBSD. put them under NetBSD specific tree.

Fix netbsd build with "stdbuild"

A bug was introduced in #930 which caused netbsd to not link to libm.

r? @alexcrichton

Fix a #[cfg] attribute

It looks like this was a mistake of #930 but should be easy to fix!

It looks like this was a mistake of #930 but should be easy to fix!

Link to libgcc when statically linking musl

On some architectures (e.g. aarch64) musl depends on some libgcc functions (`__addtf3`, `__multf3`, `__subtf3`) for `long double` arithmetic that it uses internally. Unfortunately we don't provide these functions in compiler-builtins, so we instead need to get them from libgcc.

Fixes:
https://github.com/rust-lang/rust/issues/46651
https://github.com/rust-lang-nursery/compiler-builtins/issues/201
https://github.com/rust-lang-nursery/compiler-builtins/issues/217

Bump ctest from `482c7f0` to `5c53723`

Bumps [ctest](https://github.com/alexcrichton/ctest) from `482c7f0` to `5c53723`.
<details>
<summary>Commits</summary>

- [`5c53723`](https://github.com/alexcrichton/ctest/commit/5c537236d150da311d67b8ccf4c3c49987b92c8d) Update libc dep
- See full diff in [compare view](https://github.com/alexcrichton/ctest/compare/482c7f0643942174a802d89ad7d460e89b576ed3...5c537236d150da311d67b8ccf4c3c49987b92c8d)
</details>
<br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

---

**Note:** This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking `Bump now` in your [Dependabot dashboard](https://app.dependabot.com).

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>