Convert query_range into an iterator.

This is significantly faster, especially for large/deep trees, since it
avoids allocating so much (a single backing stack that only grows a few
times).

    test bench_large_range_query       ... bench:     36122 ns/iter (+/- 9220)
    test bench_large_range_query_iter  ... bench:      6164 ns/iter (+/- 472)
    test bench_medium_range_query      ... bench:       488 ns/iter (+/- 141)
    test bench_medium_range_query_iter ... bench:       154 ns/iter (+/- 85)
    test bench_small_range_query       ... bench:        88 ns/iter (+/- 36)
    test bench_small_range_query_iter  ... bench:        79 ns/iter (+/- 14)

This also reduces the number of `contains` checks to 1 for each point
yielded, down from `O(depth(p))` in the old version.
Factor the common `region` field into its own struct.

As a nice side effect, this stops the `Bucket` and `Branch` variants
being publicly exposed (and thus stops people from fiddling with the
internals when they shouldn't). This reduces code duplication, and seems
to make the `query_range` iterator slightly faster, large goes from
6164 to 5951 (presumably due to smaller code size).
Merge pull request #1 from huonw/query_range_iter

Convert query_range to an iterator & factor the region field out of the variants
Replace the unsafe `empty_iterator` function with `(&[]).iter()`.

Strangely enough that form works, but `[].iter()` doesn't. Either way,
we can now avoid unsafety; yay!