Track kind of closure in upvar categorization

Keep track of the kind of closure responsible for an upvar
Categorize upvars in `Fn` unboxed closures as freely aliasable

This causes borrowck to correctly reject mutation or mutable borrows
of upvars in `Fn` unboxed closures since the closure environment is
aliasable.

This also tracks the responsible closure in the aliasability
information returned and uses it to give a helpful diagnostic.

Closes issue #17780
Fix unit test that was illegally mutating an upvar
Add regression test for issue #17780
Fix target-feature codegen option syntax in rustc man page.

The man page stated that the list of features was space-separated when
it's actually comma-separated.
Clarify that assigning/comparing different tuple types to one another won't compile
Re-exports core::str::Utf16CodeUnits in std::str

Closes #17751
Fix the most egregious instances of "local ambiguity: multiple parsing options..." error in macros, which often occurs when trying to match parts of Rust syntax.
For example, this matcher: `fn $name:ident( $($param:ident : $pty:ty),* )` would fail when parsing `fn foo()`, because macro parser wouldn't realize that an ident cannot start with `)`.

This resolves #5902, and at least partially mitigates #9364 and #3232.
Guide: Fix inconsistency in 'Marcos' section

The old version switched in between examples from the value `5i` to `"Hello"`
and back. Additionally, the code generated by `rustc print.rs
--pretty=expanded` is not as verbose anymore.
Rename RELEASES.txt to RELEASES.md. It's markdown.
Update RELEASES.md for 0.12.0
Update AUTHORS.txt for 0.12.0
Update per feedback
Update html_root_url for 0.12.0 release
Fix keyword table

Markdown tables require a header, and we don't want one.

Fixes #17528
More relnotes tweaks
auto merge of #17836 : typelist/rust/guide-tuples, r=steveklabnik

Currently, the Guide says tuples "are only equivalent if the arity, types, and values are all identical", before presenting an example that uses `==` to compare two tuples whose arity and contained types match. This is misleading, because it implies that `==` can dynamically check whether two tuples have the same arity and contained types, whereas trying to do this would lead to a compiler error.

I tried to avoid destroying the flow of this section, but I'm not sure if I've been successful.
Add `abstract`, `final`, and `override` to reserved keywords
Fix unclear macros documentation.
Remove use of `final` and `override` (now reserved)