[WIP] Big Deedle

This still needs a bit of work before we can merge it, but it is getting closer (in particular, there are a few changes in the normal parts of Deedle that can make things slower). 

The "Big Deedle" frame now supports the two operations we discussed. Filtering by specific value is done by `filterRowsBy`, filtering by arbitrary condition (using scan) is work-in-progress, but it can be done by adding a new column (using `df.Rows |> Series.map`) and then by calling `filterRowsBy`. In the current version, this reads the whole row in memory (which I'm going to fix).

Here is a summary of the changes to the core parts of Deedle:

 * Every instance of a frame now keeps `indexBuilder` and `vectorBuilder` and propagates them when creating new frames (series was already doing this)

 * I had to change how `frame.Rows` works - this is subtle, but essentially, we always have to build new series (row series) from existing vectors if we want to keep things virtual (in BlockStore case, we need existing `IRowIndex`). This needs some more optimizations.

 * Printing is now done more nicely using a new `GetAddressRange` operation. This lets us take first 15 and last 15 rows and print them (without evaluating the rest of the frame)

 * It is possible to create "two-way" mapping between vectors. This is exposed using `Series.transform` and it required change to `Vector.SelectMissing`. The idea is that you can create a vector (e.g. `DateTimeOffset`) from another vector (e.g. `int64` ticks) and then search for values in the new vector, just by translating the value to the original vector. This does not actually help us with BlockStore (where we have separate column with ticks & offset and so the situation is harder), but it sounds useful/interesting.

 * The operation `Frame.filterRowsBy` makes it possible to filter a frame by looking for specific values in a given column. To implement this, I had to add `Search` on vector (this is not yet implemented for ordinary in-memory vectors)

 * The `Select` operation on Series is also different (so that it can operate lazily). This needs some perf testing to make sure we are not making ordinary projection slower.

 * Finally, to enable the search & filtering operations, I changed the `GetRange` operation on vectors to use a more general `VectorRange` type, which can be either `Range of int64 * int64`, but it can also be any sequence of indices (produced by scanning) or custom (i.e. wrapped BlockStore `IRowIndex`)
Why lazy here? Isn't it just evaluated on the next line?