I just removed `pub mod` from `core.rc` and then got everything to compile again. One thing I'm worried about is an import like this:

```rust
use a;
use a::b;

mod a {
  pub type b = int;
}
mod b {
  use a;    // bad
  use a::b; // good
}
```

I'm not sure if `use a::b` being valid is a bug or intended behavior (same question about `use a`). If it's intended behavior, then I got around these modules not being public by only importing the specific members that are necessary. Otherwise that probably needs an open issue.

This rather sprawling branch refactors the borrow checker and much of the region code, addressing a number of outstanding issues. I will close them manually after validating that there are test cases for each one, but here is a (probably partial) list:

  - #4903: Flow sensitivity
  - #3387: Moves in overloaded operators
  - #3850: Region granularity
  - #4666: Odd loaning errors
  - #6021: borrow check errors with hashmaps
  - #5910: @mut broken

cc #5047

(take 5)

Support #5297

install.mk : install-runtime-target added for conveneice
                 automatically push runtime library to android device

test.mk : expanded to support android test automation with adb

compiletest : expanded to support android test automation with adb

Moving the trait into `core` allows it to be added to the `num::Float` trait.

I have also added and `assert_approx_eq!` macro. This is useful fo making approximate assertions on types that implement the `ApproxEq` trait.

Examples:

~~~rust
// using the default epsilon value
assert_approx_eq!(1.0000001f, 1.0f);

// using a custom epsilon value
assert_approx_eq!(1.000001f, 1.0f, 1.0e-5);

// fails with: "left: 1.00001 does not approximately equal right: 1"
assert_approx_eq!(1.00001f, 1.0f);
~~~

Conflicts:
	src/libcore/core.rc
	src/libcore/hashmap.rs
	src/libcore/num/f32.rs
	src/libcore/num/f64.rs
	src/libcore/num/float.rs
	src/libcore/num/int-template.rs
	src/libcore/num/num.rs
	src/libcore/num/strconv.rs
	src/libcore/num/uint-template.rs
	src/libcore/ops.rs
	src/libcore/os.rs
	src/libcore/prelude.rs
	src/libcore/rt/mod.rs
	src/libcore/unstable/lang.rs
	src/librustc/driver/session.rs
	src/librustc/middle/astencode.rs
	src/librustc/middle/borrowck/check_loans.rs
	src/librustc/middle/borrowck/gather_loans.rs
	src/librustc/middle/borrowck/loan.rs
	src/librustc/middle/borrowck/preserve.rs
	src/librustc/middle/liveness.rs
	src/librustc/middle/mem_categorization.rs
	src/librustc/middle/region.rs
	src/librustc/middle/trans/base.rs
	src/librustc/middle/trans/inline.rs
	src/librustc/middle/trans/reachable.rs
	src/librustc/middle/typeck/check/_match.rs
	src/librustc/middle/typeck/check/regionck.rs
	src/librustc/util/ppaux.rs
	src/libstd/arena.rs
	src/libstd/ebml.rs
	src/libstd/json.rs
	src/libstd/serialize.rs
	src/libstd/std.rc
	src/libsyntax/ast_map.rs
	src/libsyntax/parse/parser.rs
	src/test/compile-fail/borrowck-uniq-via-box.rs
	src/test/compile-fail/regions-infer-borrow-scope-within-loop.rs
	src/test/run-pass/borrowck-nested-calls.rs

r? (for #3326)

The previous example was erroneously attempting to destroy
uninitialized memory, which was often zeroed (masking the bug).

transitional patch to resolve compile/link failure on android

after #6161 landed, I've encountered below errors since android does not support glob in libc.

/opt/ndk_standalone/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/yichoi/rust_work/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/arm-linux-androideabi/lib/libcore-c3ca5d77d81b46c1-0.7-pre.so: error: undefined reference to 'glob'

/opt/ndk_standalone/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld: /home/yichoi/rust_work/build/x86_64-unknown-linux-gnu/stage1/lib/rustc/arm-linux-androideabi/lib/libcore-c3ca5d77d81b46c1-0.7-pre.so: error: undefined reference to 'globfre

Since android does not have `glob.h`, `glob_t` definition comes from
https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/vSH6MWPD0Vk

#6100 should be resolved.

The previous example was erroneously attempting to destroy
uninitialized memory, which was often zeroed (masking the bug).

In commit d7f5e437 "core::rt: Add the local heap to newsched tasks",
local_malloc and local_free have become rather big and their forced
inlining causes quite a bit of code bloat. Compile times for crates
affected by the bloat (e.g. rustc) improve, while others (e.g. libstd)
seem to be unaffected, so I guess the inlining doesn't gain us much.

Sizes:
```
               | librustc   | libsytax
---------------|–-----------|------------
with inlining  | 18,547,824 |  7,110,848
w/o inlining   | 15,092,040 |  5,518,608