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.
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.
auto merge of #17838 : vadimcn/rust/macros, r=alexcrichton
auto merge of #17840 : Sawyer47/rust/issue-17751, r=huonw

Closes #17751
add #[experimental] as_string/as_vec functions

This provides a way to pass `&[T]` to functions taking `&U` where `U` is
a `Vec<T>`. This is useful in many cases not covered by the Equiv trait
or methods like `find_with` on TreeMap.
auto merge of #17447 : thestinger/rust/silly_string, r=aturon

This provides a way to pass `&[T]` to functions taking `&U` where `U` is
a `Vec<T>`. This is useful in many cases not covered by the Equiv trait
or methods like `find_with` on TreeMap.