Remove support for targets without libc

[gnzlbg]

@japaric correctly pointed out in #375 that the libc crate is for linking against libc.

We currently have a lot of hacks and workarounds to "support" a variety of targets that do not have a libc, are often only interested in c types and would be better served by using the cty crate, and that actually we don't really "support" because we don't even test that we build for these targets and technically we can't test that the ABI specified here matches that of the target's libc because... there isn't any.

In particular, for some targets without a libc, currently libc is empty. That's the approach that the winapi crate follows on linux but is not the approach that mach follows on osx.

cc @alexcrichton @malbarbo I think we should clean up libc from supporting these targets and make clear in the README what libc is for.

[alexcrichton]

@gnzlbg given our discussion on IRC, would you be ok closing this?

[gnzlbg]

Yes, to summarize the discussion: libc should always compile. In targets that are not supported (e.g. because they haven't been implemented yet, have no libc, etc.), the crate should just be empty. This is also what winapi-rs does.

I discussed this with @retep998 as well, and this approach has pros and cons.

The big pro is that if code that uses libc gets compiled to an unsupported platform, it might just work as long as the dependencies don't use libc for that platform. This is particularly important for libc because many targets have a libc of some sorts.

The downsides are that libc and winapi are then downloaded and compiled on platforms in which they are not used, and their presence in the dependency tree can affect dependency resolution (e.g. libc pulls in std by default which has caused some headaches). And also, that when people do try to use them in unsupported platforms, the compilation errors are suboptimal (e.g. function not found).

TBH I don't think that these downsides are worth fixing in these crates. It is unclear which way is the right way to do things (there might not be a right way here). These fixes definitely don't add enough value in my opinion to justify the breakage they would cause. libc in particular is a very small crate, downloading it and not using it isn't a big deal, and if it is, upstream crates can fix that.

The mach crate, however, already fails to compile / link on non apple targets, so I'll release a new version that chooses the "opposite" approach: explicitly failing to compile on unsupported platforms. That pretty much forces users to include mach as a target-dependent dependency, but this is already what all users are doing, and now it will produce a nice error message instead of symbol not found.