This change removes the AbiSet from the AST, converting all usage to have just
one Abi value. The current scheme selects a relevant ABI given a list of ABIs
based on the target architecture and how relevant each ABI is to that
architecture.

Instead of this mildly complicated scheme, only one ABI will be allowed in abi
strings, and pseudo-abis will be created for special cases as necessary. For
example the "system" abi exists for stdcall on win32 and C on win64.

Closes #10049

1778b636 provided the guarantee of no
`exchange_free` calls for ~ZeroSizeType, so a sentinel can now be used
without overhead.

Closes #11998

Note: "different to" is not exactly incorrect, but "different from" is more
commonly accepted in both US and Commonwealth English, and also more
consistent with other usage within this tutorial.

There are actually three traits listed.

Remove some statements that used to refer to similarities between `mod` and
`extern mod`, before the latter was renamed to `extern crate`.

Fixes #10474

A vector can reuse its allocation (and the allocations/resources of any
contained values) when cloning into an already-instantiated vector, so
we might as well do so.

The .def.in files haven't been necessary since the switch to static linking
awhile back.

The recent pull request to remove libc from libstd has hit a wall in compiling
on windows, and I've been trying to investigate on the try bots as to why (it
compiles locally just fine). To the best of my knowledge, the LLVM section
iterator is behaving badly when iterating over the sections of the libc DLL.

Upon investigating the LLVMGetSectionName function in LLVM, I discovered that
this function doesn't always return a null-terminated string. It returns the
data pointer of a StringRef instance (LLVM's equivalent of &str essentially),
but it has no method of returning the length of the name of the section.

This commit modifies the section iteration when loading libraries to invoke a
custom LLVMRustGetSectionName which will correctly return both the length and
the data pointer.

I have not yet verified that this will fix landing liblibc, as it will require a
snapshot before doing a full test. Regardless, this is a worrisome situation
regarding the LLVM API, and should likely be fixed anyway.

The details are outlined in the first commit. 

Closes #10453

This commit tightens up the restriction on types used to index slices to require
exactly `uint` indices. Previously any integral type was accepted, but this
leads to a few subtle problems:

  * 64-bit indices don't make much sense on 32-bit systems
  * Signed indices for slices used as negative indexing isn't implemented

This was discussed at the recent work week, and also has some discussion on
issue #10453.

Closes #10453