Bump to 0.2.51

Pulls in the new wasi target support!

Add mq_getfd_np() on FreeBSD and fix mqd_t on DragonFlyBSD

[`mq_getfd_np()` was added in FreeBSD 11](https://svnweb.freebsd.org/base/stable/11/include/mqueue.h?revision=306905&view=markup). I'm already using it in my [posixmq crate](https://github.com/tormol/posixmq) for mio/kqueue integration, and I've tested it both in virtualbox and on Cirrus-CI.

[`mqd_t` in an `int` on DragonFlyBSD](https://github.com/DragonFlyBSD/DragonFlyBSD/blob/e7ab884bd49753f8884eb597d10d6569a08fa0df/sys/sys/types.h#L139) even though it's a pointer on FreeBSD, because [DragonflyBSD's implementation is based on NetBSD](https://github.com/DragonFlyBSD/DragonFlyBSD/commit/f2df0f7ca6de3f944dcbfb9923750d7c88984535). The definitions for `mq_attr` are already separate and correct.
Does fixing this count as a breaking change? I think the current definition will work in most cases, because IIRC the calling convention means that `mqd_t` is always passed via registers, the upper 32 bits might just contain garbage.
I've *not* tested this change on DragonFlyBSD.

I want to add mq symbols for solarish, but is the CDDL license compatible with Apache-2.0 and MIT?

Add intial support for wasm32-unknown-wasi

This target is [being proposed][LINK] int he rust-lang/rust repository
and this is intended to get coupled with that proposal. The definitions
here all match the upstream reference-sysroot definitions and the
functions all match the reference sysroot as well. The linkage here is
described more in detail on the Rust PR itself, but in general it's
similar to musl.

Automatic verification has been implemented in the same manner as other
targets, and it's been used locally to develop this PR and catch errors
in the bindings already written (also to help match the evolving sysroot
of wasi). The verification isn't hooked up to CI yet though because
there is no wasi target distributed via rustup just yet, but once that's
done I'll file a follow-up PR to execute verification on CI.

[LINK]: https://github.com/rust-lang/rust/pull/59464

This target is [being proposed][LINK] int he rust-lang/rust repository
and this is intended to get coupled with that proposal. The definitions
here all match the upstream reference-sysroot definitions and the
functions all match the reference sysroot as well. The linkage here is
described more in detail on the Rust PR itself, but in general it's
similar to musl.

Automatic verification has been implemented in the same manner as other
targets, and it's been used locally to develop this PR and catch errors
in the bindings already written (also to help match the evolving sysroot
of wasi). The verification isn't hooked up to CI yet though because
there is no wasi target distributed via rustup just yet, but once that's
done I'll file a follow-up PR to execute verification on CI.

[LINK]:

Don't fix asmjs and wasm32 build jobs

This doesn't fix the jobs, but at least now libc-test reports no errors, even though they still fail to link.

Add essential target_vendor check for sgx

As discussed in issue [57231](https://github.com/rust-lang/rust/issues/57231

), the current `sgx` branch only works for Fortanix's sgx platform. So the `target_vendor` should be checked here.

Signed-off-by: Yu Ding <dingelish@gmail.com>

Signed-off-by: Yu Ding <dingelish@gmail.com>

Bump to 0.2.50

I'm using libnx-rs too, and it'd be nice to have #1278 in a release.

Upgrade bunch of EOL docker images to Ubuntu 18.04

When upgrading other Dockerfiles (not modified in this PR) they fail with different errors:
https://travis-ci.com/mati865/libc/jobs/181623075
https://travis-ci.com/mati865/libc/jobs/181623059
https://travis-ci.com/mati865/libc/jobs/181623067

I think it's because of these 2 commits in glibc:
https://sourceware.org/git/?p=glibc.git;a=commit;h=b05cb613e7ae507680c8d914b3e788eea782c0d6
https://sourceware.org/git/?p=glibc.git;a=commit;h=2dba5ce7b8115d6a2789bf279892263621088e74

I have no idea how to fix them so leaving it for somebody who knows what to do.

Check that more targets build

add HermitCore support even if it doesn't have a UNIX interface

Currently, we redefine the interface between the HermitCore kernel (https://hermitcore.org) and Rust’s standard library. In the future, it will not depend on a POSIX-compatible C library. Consequently, we add the support of HermitCore if the "unix" environment isn’t set. It will be great to integrate this patch because it would simplify our development. The classical interface is still supported and part of the subdirectory "unix".

x86_64-uclibc-l4re: fix syntax error + linter issues

-   fix syntax error in expand_align macro
-   fix errors due to doubly defined symbols / functions for
    x86_64-uclibc

vm_size_t does not exist on OpenBSD and Bitrig

unbreak openbsd and bitrig after #1294

r? @gnzlbg

Add vm_size_t