bcolz, blz, and chunks

This creates a decent out-of-core dataframe using `bcolz/blz` a chunking mechanism, and in-memory computational systems like numpy/pandas.

Along the way we've added the following pieces

*  PyTables backend
*  BLZ/BColz backends (see note on relation below)
*  Chunking meta backend
*  `chunks` dispatched function

### Example

```Python
In [2]: from blaze import *
In [3]: import h5py
In [4]: import bcolz
```
Get out HDF5 file using `h5py`, migrate to `bcolz`
```Python
In [5]: dset = h5py.File('/home/mrocklin/data/bitcoin/data-code/btc.hdf5')['/user_edges']

In [6]: b = into(bcolz.ctable, dset, rootdir='/home/mrocklin/data/bitcoin/data-code/btc.bcolz')
In [7]: b
Out[7]: 
ctable((37450461,), [('transaction', '<i8'), ('sender', '<i8'), ('recipient', '<i8'), ('timestamp', '<i8'), ('value', '<f8')])
  nbytes: 1.40 GB; cbytes: 494.66 MB; ratio: 2.89
  cparams := cparams(clevel=5, shuffle=True, cname='blosclz')
  rootdir := '/home/mrocklin/data/bitcoin/data-code/btc.bcolz'
[(1, 2, 2, 20130410142250, 24.375) (1, 2, 782477, 20130410142250, 0.7709)
 (2, 620423, 4571210, 20111227114312, 614.17495129) ...,
 (15898623, 4391902, 4391902, 20090108205544, 50.0)
 (15898624, 1310409, 1310409, 20090108205425, 50.0)
 (15898625, 824760, 824760, 20090103121505, 50.0)]
```

Lets wrap that up in a Blaze Table to get a nicer interface

```Python
In [8]: t = Table(b)

In [9]: t
Out[9]: 
    transaction   sender  recipient       timestamp       value
0             1        2          2  20130410142250   24.375000
1             1        2     782477  20130410142250    0.770900
2             2   620423    4571210  20111227114312  614.174951
3             2   620423          3  20111227114312  128.040520
4             3        3     782479  20130410142250   47.140520
5             3        3          4  20130410142250  150.000000
6             4    39337      39337  20120617120202    0.310818
7             4    39337          3  20120617120202   69.100000
8             5  2071196    2070358  20130304143805   61.602352
9             5  2071196          5  20130304143805  100.000000
...

In [10]: t[t.recipient == t.sender]  # fast selections via numexpr
Out[10]: 
    transaction   sender  recipient       timestamp      value
0             1        2          2  20130410142250  24.375000
1             4    39337      39337  20120617120202   0.310818
2             9   782483     782483  20130306075701  10.908380
3            10   782483     782483  20130410142250   2.908380
4            11  1450491    1450491  20120707061604   4.047011
5            13        8          8  20130405163109   0.035100
6            17        8          8  20130203102700   4.635373
7            18        8          8  20130405162515   0.269000
8            22   782490     782490  20130410142250   0.665313
9            51      532        532  20121205091743   0.015837
...

In [11]: t[t.sender == 254242]
Out[11]: 
   transaction  sender  recipient       timestamp    value
0      4509156  254242    2982715  20130128123902  0.00049
1      4509156  254242         25  20130128123902  0.01500
```

`bcolz` supports some reductions like `sum` and `len`.  For others we aggregate on chunks reduced via numpy's in-memory reductions.

```Python
In [7]: t.value.sum()  # supported by bcolz directly
Out[7]: 1415132586.8

In [8]: t.value.max()  # not supported, chunks in and uses numpy
Out[8]: 500000.0
```

This chunking mechanism works decently even for somewhat complex operations like split-apply-combine.  At the moment this is slow, but I think that is because of a failure to profile and tune, not due to any inherent limitation.  Someone should profile at some point but for now, we can appreciate that this works.

```Python
In [16]: by(t, t.sender, t.value.sum())
    sender         value
0        1  2.443501e+13
1        2  4.262970e+05
2        3  3.785684e+06
3        4  7.066899e+07
4        5  3.323476e+07
5        6  6.216059e+06
6        7  8.392696e+08
7        8  6.806582e+07
8        9  6.664619e+07
9       10  3.197631e+06
```

Operations like `Join` also work but execute fairly naively.  Operations like `Sort` are not supported although a `TopK` should be pretty doable (spark likes this too.)

### BColz/BLZ

`bcolz` appears to be Francesc's continuation of `blz`.  They have almost identical interfaces with some improvements on `bcolz`.  I'm not sure what we want to do here.  Continue supporting `blz`?  Drop it in favor of `bcolz`?  At the moment I have near-copied files to establish the interface to each project.  In other words `bcolz.py` is a copy of `blz.py` with a few terms renamed.
Just to be explicit here: in previous uses of multimethod dispatch, say for something like `compute_one`, both arguments were objects of a non-class kind (descending from `object`), and `dispatch` matched on the type of those objects . For `into` the first argument is itself a class, so a little work must be done so that when I see this:

```
@dispatch(np.ndarray, np.ndarray)
def into(a, b):
    return b
```
we know that we are referring to situations like this:

```
into(np.ndarray, np.array([1,2,3,4]))
```

and not this
```
into(np.array([0,1,2,3]), np.array([1,2,3,4]))
```
If that is correct, then this function here is sort of the "entry point" for resolution for `into`. I think it deserves a comment or two.