Trim dependencies

[madsmtm]

Of particular note:

• libc is not needed in most cases, one can simply use std::os::raw
• leaky-cow seems like it existed to work around compiler limitations, these are no more

@jrmuizel I've included version bumps in here as well, would be nice if you could also do a new release after this

[madsmtm]

Ping @jdm? This would be really nice to have in winit, I'd be able to remove a lot of old cruft from that

[madsmtm]

Tests are passing for this now, would you mind taking another look?

[complexspaces]

FWIW, it would be nice if the changes here moving everything towards using std wasn't applied universally. Notably, crates like core-foundation-sys and other -sys crates that contain nothing but bindings. These didn't strictly change much in this PR, but I wanted to bring up the idea since this seemed like a good place.

You stated this goal in the PR description:

libc is not needed in most cases, one can simply use std::os::raw

However, depending on the MSRV goals (if any) that these crates have, I would argue that using libc is the better option to make more of these available in no_std contexts to anyone who may want that. I personally found it surprising this weekend to find that core-foundation-sys used std given how little it does.

A lot of the C FFI types just moved to core in recent Rust versions that obsoletes the above, but it is probably too new for these crates given how widely used they are.

[jrmuizel]

However, depending on the MSRV goals (if any) that these crates have, I would argue that using libc is the better option to make more of these available in no_std contexts to anyone who may want that. I personally found it surprising this weekend to find that core-foundation-sys used std given how little it does.

@complexspaces What's the use case for using core-foundation-sys in a no-std environment?

[complexspaces]

What's the use case for using core-foundation-sys in a no-std environment?

@jrmuizel Binary sizes, primarily.

[bors-servo]

☔ The latest upstream changes (presumably #548) made this pull request unmergeable. Please resolve the merge conflicts.

[madsmtm]

I think most of this has been done in other PRs, so I'll leave it for now