docs: don't claim struct layout is specified, but mention repr
librustc: handle repr on structs, require it for ffi, unify with packed

As of RFC 18, struct layout is undefined. Opting into a C-compatible struct
layout is now down with #[repr(C)]. For consistency, specifying a packed
layout is now also down with #[repr(packed)]. Both can be specified.

To fix errors caused by this, just add #[repr(C)] to the structs, and change
 #[packed] to #[repr(packed)]

Closes #14309

[breaking-change]
Add #[repr(C)] to all the things!
manual: fix link
Add detailed note about Substs to ty_enum
liblibc: don't use int/uint for intptr_t/uintptr_t

int/uint aren't considered FFI safe, replace them with the actual type they
represent (i64/u64 or i32/u32). This is a breaking change, but at most a cast
to `uint` or `int` needs to be added.

[breaking-change]
libgreen: use FFI-safe types
Stage #[repr(packed)] in std::rt
Fix FFI guide
auto merge of #16499 : cmr/rust/struct-undef-repr, r=pcwalton

r? @pcwalton
Parameterize indent in PrettyEncoder
auto merge of #16601 : cybergeek94/rust/master, r=alexcrichton

Previously, `PrettyEncoder` indented a magic constant of 2 spaces per level, which may be fine for most uses but in my use case I would like to allow the user to specify the indent step for the outputted JSON in my program.

This is small change that does not break any existing code whatsoever, and does not change the behavior of existing uses. `PrettyEncoder::new()` still uses the default of 2.

I couldn't think of any simple tests for this change. The obvious one would be to check the outputted JSON for the correct number of spaces per indent level, but I think that would be more complex than the actual change itself and test little besides correctness and consistency, which can be verified visually. There's already a test for correct parsing of pretty-printed JSON that should still pass with this change.