Support an alternate for syntax that calls a higher-order function

The last argument of the call must be a block, and the type of this
argument must a function returning bool. `break` and `cont` are
supported in the body of the block, and return `false` or `true` from
the function. When the end of the function is reached, `true` is
implicitly returned.

    for vec::all([1, 2, 3]) {|elt|
        if elt == 2 { break; }
        log(error, elt);
    }

Issue #1619
Support returning from loop blocks

The code is somewhat invasive, but it seems hard to do this in a
clean way, since the design itself involves a bunch of 'action
at a distance'.

Issue #1819
Add vec::each, vec::eachi, and list::each

For use with the new for construct.

Issue #1619
Register new snapshot
Move some code over to iterator-for to see how it performs.
Emergency safe-ref-checker maintenance

It still has some big problems, but at least it more or less
understands block arguments now.

Closes #1925
Tweak relnotes.
Prep docs before pdf.
Minor typo fixes.
rust: Remove extensions' dependency on the session
core: Rename iter::to_list to to_vec. Closes #2056
emacs: Make 'mut' a keyword
make type_kind exhaustive, add an entry for type_self (in particular)
Enforce mutability declarations in classes; correct shapes for classes

1. Enforce mutability declarations on class fields. Don't allow any
mutation of class fields not declared as mutable (except inside the
constructor).

2. Handle classes correctly in shape (treat classes like records).
Add config.stamp to .gitignore
Make sure type_use.rs doesn't get lost in recursive enums

Closes #2059
adding uv::direct and beginning to work out tcp request case

lots of changes, here.. should've commited sooner.
- added uv::direct module that contains rust fns that map, neatly, to
the libuv c library as much as possible. they operate on ptrs to libuv
structs mapped in rust, as much as possible (there are some notable
exceptions). these uv::direct fns should only take inputs from rust and,
as neccesary, translate them into C-friendly types and then pass to the
C functions. We want to them to return ints, as the libuv functions do,
so we can start tracking status.
- the notable exceptions for structs above is due to ref gh-1402, which
prevents us from passing structs, by value, across the Rust<->C barrier
(they turn to garbage, pretty much). So in the cases where we get back
by-val structs from C (uv_buf_init(), uv_ip4_addr(), uv_err_t in callbacks)
, we're going to use *ctypes::void (or just errnum ints for uv_err_t) until
gh-1402 is resolved.
- using crust functions, in these uv::direct fns, for callbacks from libuv,
will eschew uv_err_t, if possible, in favor a struct int.. if at all
possible (probably isn't.. hm.. i know libuv wants to eventually move to
replace uv_err_t with an int, as well.. so hm).
- started flushing out a big, gnarly test case to exercise the tcp request
side of the uv::direct functions. I'm at the point where, after the
connection is established, we write to the stream... when the writing is
done, we will read from it, then tear the whole thing down.

overall, it turns out that doing "close to the metal" interaction with
c libraries is painful (and more chatty) when orchestrated from rust. My
understanding is that not much, at all, is written in this fashion in the
existant core/std codebase.. malloc'ing in C has been preferred, from what
I've gathered. So we're treading new ground, here!
some more stuff for libuv dealing w/ 1402.. should go away soon
changing ctypes:: to libc:: and impl of uv::direct::write()
impl of rustrt::rust_uv_write in c++ and whitespace cleanup