Throwing in upcall_fail ends up running lots of code in the red zone. To avoid
it we have the personality function figure out which stack it's on and switch
as needed.

Shims need to play with the stack limit, upcalls don't. Only one upcall,
upcall_fail is allowed to catch, and we need a find a way to get rid of that
catch as well because it results in _Unwind_Resume running off the end of the
Rust stack.

This existed to make up for the lack of stack growth, and wasn't generally
safe.

We should probalby warn when defining a method foo on {foo: int} etc.

This should reduce the amount of useless typevars that are allocated.

Issue #1227

And fix a bug where importing anything from an external module would
import all impls in the module.

Issue #1227

This reverts commit 68f4849f.

It's not compatible with the subtlety of __morestack

Preventing us from writing beyond our allocations is _what valgrind does_,
so telling valgrind not to let us write to the end of the stack isn't
buying anything.

cargo: shorten a line

cargo: support distributed package indexes

Indexes are listed in ~/.cargo/sources.json and ~/.cargo/local-sources.json, the
former of which is stored in the rust source tree in src/cargo. Each entry in
either of these files is a source, which is a dictionary with (currently) a
single key, "url". The supplied url should point to a json list, each element of
which should be a dictionary with four keys: "name", "uuid", "url", and
"method". The name and uuid serve to identify the package; the method describes
how to fetch the package; the url describes where to fetch it from. Currently
supported methods are "git", "http", and "file".
Signed-off-by: NElly Jones <elly@leptoquark.net>

I haven't thought too deeply about this, but I think I was telling the
unwinder to use the stack pointer for the wrong frame when unwinding. Not sure
how that could have worked at all, but this results in the correct alignment
for cleanups.