complete btree rewrite

Replaces BTree with BTreeMap and BTreeSet, which are completely new implementations.
BTreeMap's internal Node representation is particularly inefficient at the moment to
make this first implementation easy to reason about and fairly safe. Both collections
are also currently missing some of the tooling specific to sorted collections, which
is planned as future work pending reform of these APIs. General implementation issues
are discussed with TODOs internally

[breaking-change]

Still waiting on compilation/test/bench stuff locally, but the edit-distance on any errors should be very small at this point. This is ready to be reviewed.
We *could* have `pub struct BTreeMap<K, V, B: BTreeB> { ... b: B }` which can be instantiated with (something like) either:

- `struct CompileTime<static n: uint>;` (i.e. zero sized)
- `struct Dynamic(uint);`
- `struct SensibleChoice(uint);`

with a trait like `trait BTreeB { fn new<K, V>() -> Self; fn get_b(&self) -> uint; }`. I don't think we should tackle this in this PR (i.e. please don't), there's already enough code.

> Of course this falls over a bit when K is actually a collection of some kind like a String

I don't think so, the inline-memory size is the thing that matters here (right?), so `size_of` still returns the relevant thing.