This speeds up rustc on #25916 from 1.36Â0.022s to 1.326Â0.025s

As title :-)
Part of #24407.

r? @Manishearth

Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to references to make them more obvious, without using any characters with actual meaning in the rust language (like `&` or previously `~`).

r? @steveklabnik 

Fixes #27450.

r? @steveklabnik

Keeping integer values and integer references in the "value" columns made the examples quite difficult for me to follow. I've added unicode arrows to make references more obvious, without using a character with actual meaning in the rust language (like `&` or previously `~`).

Fixes #27450.

Part of #24407.
r? @Manishearth 

Turn nonzeroing move hints back off by default.

Works around bugs injected by PR #26173.

 * (@pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them.)

 * When the bugs are fixed, we will turn nonzeroing move hints back on by default.

Fix #27401

Fix #27401.

This is a temporary workaround for the bugs that have been found in
the implementation of PR #26173.

 * pnkfelix is unavailable in the short-term (i.e. for the next week) to fix them.

 * When the bugs are fixed, we will turn this back on by default.

(If you want to play with the known-to-be-buggy optimization in the
meantime, you can opt-back in via the debugging option that this
commit is toggling.)

This ended up being a bigger refactoring than I thought, as I also cleaned a few ugly points in rustc. There are still a few areas that need improvements.

Performance numbers:
```
Before:
572.70user 5.52system 7:33.21elapsed 127%CPU (0avgtext+0avgdata 1173368maxresident)k
llvm-time: 385.858

After:
545.27user 5.49system 7:10.22elapsed 128%CPU (0avgtext+0avgdata 1145348maxresident)k
llvm-time: 387.119
```

A good 5% perf improvement. Note that after this patch >70% of the time is spent in LLVM - Amdahl's law is in full effect.

Passes make check locally.

r? @nikomatsakis 

1. this isn't actually true about diabetes
2. people with diabetes will get *real sad* when reading this
3. it isn't actually necessary.

r? @Gankro 

r? @steveklabnik

This search happens a lot! Locally, compiling hyper sees the following improvements:

before

real    0m30.843s
user    0m51.644s
sys     0m2.128s

real    0m30.164s
user    0m53.320s
sys     0m2.208s

after

real    0m28.438s
user    0m51.076s
sys     0m2.276s

real    0m28.612s
user    0m51.560s
sys     0m2.192s

1. this isn't actually true about diabetes
2. people with diabetes will get *real sad* when reading this
3. it isn't actually necessary.

This search happens a lot! Locally, compiling hyper sees the following improvements:

before

real    0m30.843s
user    0m51.644s
sys     0m2.128s

real    0m30.164s
user    0m53.320s
sys     0m2.208s

after

real    0m28.438s
user    0m51.076s
sys     0m2.276s

real    0m28.612s
user    0m51.560s
sys     0m2.192s

I got a bit confused reading the guide over why all of a sudden there was an asterisk in the code. I was explained what it was there for in the IRC, and I think it should added it to the docs to prevent any further confusion!

This pull request implements the functionality for [RFC 873](https://github.com/rust-lang/rfcs/blob/master/text/0873-type-macros.md). This is currently just an update of @freebroccolo's branch from January, the corresponding commits are linked in each commit message.

@nikomatsakis and I had talked about updating the macro language to support a lifetime fragment specifier, and it is possible to do that work on this branch as well. If so we can (collectively) talk about it next week during the pre-RustCamp work week.

* Some clarifying rephrasing.
* Rename B.x back to B.a.
* Make null pointer optimization section bit more concrete.

r? @Gankro 

Perf numbers:

Before this patchset:
572.70user 5.52system 7:33.21elapsed 127%CPU (0avgtext+0avgdata 1173368maxresident)k
llvm-time: 385.858

After this patch:
557.84user 5.73system 7:22.10elapsed 127%CPU (0avgtext+0avgdata 1142848maxresident)k
llvm-time: 385.834

nice 2.5% perf improvement

In Section 3.2, TARPL says that "standard allocators (including jemalloc, the one used by default in Rust) generally consider passing in 0 for the size of an allocation as Undefined Behaviour."
However, the C standard and jemalloc manual says allocating zero bytes
should succeed:

- C11 7.22.3 paragraph 1: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
- [jemalloc manual](http://www.freebsd.org/cgi/man.cgi?query=jemalloc&sektion=3): "The malloc and calloc functions return a	pointer	to the allocated memory if successful; otherwise a NULL pointer is returned and errno is set to ENOMEM."
    + Note that the description for `allocm` says "Behavior	is undefined if	size is 0," but it is an experimental API.

r? @Gankro 

Fixes #27532

Thanks @eefriedman for the test.