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

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

adjust PTHREAD_STACK_MIN to current value on OpenBSD

adjust `PTHREAD_STACK_MIN` to current value on OpenBSD, and while here, generate the right file in test_openbsd()

I should say that I am a bit disappointed. If I didn't miss anything, the related change for `PTHREAD_STACK_MIN` is near to one year old. And clearly with the name error in `test_openbsd()` something wasn't clean.

while here, generate the right file in test_openbsd()

Link docs for other platforms in docs.rs

Verify that only non-technical breaking changes are applied to libc

Closes #270 .

cc @alexcrichton so this would be a solution to #270 that uses rust-semverver to check that the API of `libc` contains only non-technical breaking changes.

This is a WIP and uses a fork of `rust-semverver` for now, but I've sent PRs upstream already. This is the only idea I have for solving #270 . `rust-semverver` is not perfect, but it can deal with functions, consts, and simple structs just fine, and that's pretty much everything that libc uses.

cc @ibabushkin

Some other notes:

* we have to compile `rust-semverver` for each toolchain version, and it depends on `cargo` so we have to build ~160 dependencies. Using `cache: cargo` breaks everything.

Add arm-uclibc definitions

I used `buildroot-2017.05` to build armv7 cross compiler, `uclibc-1.0.24` and `libc-test`. I've executed `libc-test` on armv7-based SoC, using modified `libc-test` to account for the environment. Modified libc-test is not included in this PR because it is too dependent on cross compilation and execution environment.

Fix typo in `sem_t` alignment for mips32-uclibc

Closes #270 .

cleanup libc-test for OpenBSD

here a cleanup for libc-test for OpenBSD

Some elements (compat for old and now unsupported OpenBSD versions) could be removed, but I think it is better to address them after this PR is merged.

the testsuite for OpenBSD still pass with it (well, with #1280)

r? @gnzlbg