Flag all TLS functions as inline(never)

There's lots of fun rationale in the comments of the diff.

Closes #11683
xfail another external macro test on android
auto merge of #11719 : brson/rust/bleh, r=alexcrichton
auto merge of #11711 : alexcrichton/rust/issue-11683, r=brson

There's lots of fun rationale in the comments of the diff.

Closes #11683
Allow trailing commas in argument lists and tuple patterns
auto merge of #11727 : sanxiyn/rust/trailing-comma, r=alexcrichton

Fix #6506.
Fix #7358.
Replace C types with Rust types in libstd, closes #7313
auto merge of #10943 : fhahn/rust/issue-7313-replace-c-types, r=alexcrichton

I've started working on a patch for #7313 . So far I tried to replace C types in `src/libstd/unstable/*` and related files.

So far, I have two questions. Is there a convention for passing pointers around in `std` as Rust types? Sometimes pointers are passed around as `*c_char` (which seems to be an `*i8`), `*c_void` or `*u8`, which leads to a lot of casts. E.g: [`exchange_malloc`](https://github.com/fhahn/rust/compare/issue-7313-replace-c-types?expand=1#diff-39f44b8c3f4496abab854b3425ac1617R60) used to return a `*c_char` but the function in turn only calls `malloc_raw` which returns a `*c_void`.
Is there a specific reason for this?

The second question is about `CString` and related functions like `with_c_str`. At the moment these functions use `*c_char*`. Should I replace it with `*u8` or keep it, because it's an wrapper around classical C strings?
Typo in module tutorial