[WIP] getindex performance

[willtebbutt]

Starts to address #250 . Entirely fixes the bug as described in that issue (Float64s, each call to getindex allocates nothing).

The changes include:

1. ~~introducing a layer of indirection (thanks @tpgillam for this suggestion) in the PQValue type to prevent the need to allocate when result (which is a mutable struct) is used to construct a PQValue.~~
2. moving a lot of type information into the type of ~~PQValue and~~ Column so that it can be statically resolved.
3. Replacing the parse_type closure with the ParseType{T} callable to force the compiler to specialise.

I need advice as to how to proceed (@iamed2 I would like to take you up on your offer in #250 :) ) :

1. Have I gone about this in a sensible way -- I don't have the overview of the package's architecture that you do @iamed2, so I might be missing something obvious.
2. how should I write performance tests for this? Is there a good place in runtests into which I should hook? It's a rather large file, so I'm not completely sure what a good entrance point would be.
3. What types should I be testing for performance here? Clearly floats / ints / dates etc are good targets -- do we have a collection of examples columns instantiated somewhere in the tests that I could attach some performance tests to?

edit: interestingly, it actually looks like the indirection wasn't necessary in order to remove the allocations. It appears to be the case that everything is sorted by being slightly more assertive in the specialisations that the compiler is made / allowed to perform. Even more interestingly, it doesn't even look like we need to specialise on the typeof jl_result in PQValue.