std: Speed up str::is_utf8

Use unchecked vec indexing since the vector bounds are checked by the
loop. Iterators are not easy to use in this case since we skip 1-4 bytes
each lap. This part of the commit speeds up is_utf8 for ASCII input.

Check codepoint ranges by checking the byte ranges manually instead of
computing a full decoding for multibyte encodings. This is easy to read
and corresponds to the UTF-8 syntax in the RFC.

No changes to what we accept. A comment notes that surrogate halves are
accepted.

Before:

	test str::bench::is_utf8_100_ascii ... bench: 165 ns/iter (+/- 3)
	test str::bench::is_utf8_100_multibyte ... bench: 218 ns/iter (+/- 5)

After:
	test str::bench::is_utf8_100_ascii ... bench: 130 ns/iter (+/- 1)
	test str::bench::is_utf8_100_multibyte ... bench: 156 ns/iter (+/- 3)
Rename IpAddr -> SocketAddr, extract IpAddr from SocketAddr

multicast functions now take IpAddr (without port), because they dont't
need port.

Uv* types renamed:
* UvIpAddr -> UvSocketAddr
* UvIpv4 -> UvIpv4SocketAddr
* UvIpv6 -> UvIpv6SocketAddr

"Socket address" is a common name for (ip-address, port) pair (e.g. in
sockaddr_in struct).
etc: add the `in` keyword to the emacs mode.
trans_arg_expr: Omit extra copies for rvalues

rvalues aren't going to be used anywhere but as the argument, so
there's no point in copying them. LLVM used to eliminate the copy
later, but why bother emitting it in the first place?
register snapshots
remove obsolete `foreach` keyword

this has been replaced by `for`
rm obsolete `for` support from the compiler
auto merge of #8264 : thestinger/rust/snapshot, r=Aatch
auto merge of #8217 : brson/rust/reset_stack_limit, r=pcwalton

In some scenarios upcall_rust_stack_limit fails to record the stack
limit, leaving it 0, and allowing subsequent Rust code to run into
the red zone.
auto merge of #8254 : brson/rust/libuv-mac-supp, r=pcwalton

I suspect that this is a race between process exit and the termination of
worker threads used by libuv (if I sleep before exit it doesn't leak). This
isn't going to cause any real problems but should probably be fixed at
some point.

r? @pcwalton

cc #8253
auto merge of #8237 : blake2-ppc/rust/faster-utf8, r=brson

Use unchecked vec indexing since the vector bounds are checked by the
loop. Iterators are not easy to use in this case since we skip 1-4 bytes
each lap. This part of the commit speeds up is_utf8 for ASCII input.

Check codepoint ranges by checking the byte ranges manually instead of
computing a full decoding for multibyte encodings. This is easy to read
and corresponds to the UTF-8 syntax in the RFC.

No changes to what we accept. A comment notes that surrogate halves are
accepted.

Before:

	test str::bench::is_utf8_100_ascii ... bench: 165 ns/iter (+/- 3)
	test str::bench::is_utf8_100_multibyte ... bench: 218 ns/iter (+/- 5)

After:
	test str::bench::is_utf8_100_ascii ... bench: 130 ns/iter (+/- 1)
	test str::bench::is_utf8_100_multibyte ... bench: 156 ns/iter (+/- 3)

An improvement upon the previous pull #8133
auto merge of #8243 : stepancheg/rust/ipv, r=brson

multicast functions now take IpAddr (without port), because they dont't
need port.

Uv* types renamed:
* UvIpAddr -> UvSocketAddr
* UvIpv4 -> UvIpv4SocketAddr
* UvIpv6 -> UvIpv6SocketAddr

"Socket address" is a common name for (ip-address, port) pair (e.g. in
sockaddr_in struct).

P. S. Are there any backward compatibility concerns? What is std::rt module, is it a part of public API?
auto merge of #8262 : dotdash/rust/no_rval_copies, r=pcwalton

rvalues aren't going to be used anywhere but as the argument, so
there's no point in copying them. LLVM used to eliminate the copy
later, but why bother emitting it in the first place?
Try to fix a periodic windows build failure due to broken rwildcard macro
Update LLVM
Fix build issues once LLVM has been upgraded

* LLVM now has a C interface to LLVMBuildAtomicRMW
* The exception handling support for the JIT seems to have been dropped
* Various interfaces have been added or headers have changed
Fix setting the fixed stack segment attribute on LLVM functions

At the same time create a more robust wrapper to try to prevent this type of
issue from cropping up in the future.
Add a workaround for 8199 for now
Integrate new arm patch and fix an LLVM bug

Thanks @luqama!
Merge pull request #8284 from huonw/emacs-in-kw

etc: add the `in` keyword to the emacs mode.