Towards consistent null handling

This PR includes a number of fixes to handle nulls more consistently on the query side.  These fixes were done to support a user who is leveraging the schema-less capabilities of Druid.  It's sufficient for all needs we've currently found, but I am not certain that it is comprehensive just yet.

Fixes #665 in the following manner

- return null values for all matching rows when a columns is missing (e.g. for groupBy, topN)
- treat empty string and null the same, but always return null
- allow specifying null in filters

- for multi-value dimensions, if the dimension has multiple values:   
     1. dim extraction returns null -> null
     2. missing column -> null
     3. [] -> null
     4. [""] -> [null]
     5. ["", "a"] -> [null, "a"]

- for single value dimensions
    1. missing column -> null
    2. dim extraction returns null -> null
    3. [""] -> null
    4. [] -> null



Also, on the PR is the addition of a context parameter on timeseries queries that allows it to ignore empty buckets.  I realize that this should've been separated into two PRs, but there is a bit of context behind these commits that makes that difficult.  It's just a few changes in `TimeseriesQuery`, `TimeseriesQueryEngine` and `TimeseriesQueryRunnerTest`
@xvrl re: topN

> I don't believe the other queries generate empty data entries for time buckets that don't have data, has that changed?

And yes, skipping empty buckets by default is what timeseries initially did, then I had it auto-generate empty values as an indirect mechanism of figuring out if a segment exists or not (i.e. it will generate 0's if the segment exists and there just is nothing there, where if the segment doesn't exist then it won't generate anything).  This proved to be not enough to determine that a segment isn't actually there, though.  So, while I agree with you in principle that switching back to the original "never generate empty values" behavior is more correct, the fact is that there might be people who are expecting those values to be generated for them and making this change in a backwards-incompatible manner could make it very difficult for them to actually move forward.

If we want to make the change to timeseries defaulting to not generating anything, that should be done in a subsequent version.  That allows people using the system some time to set this parameter first and rework their systems before changing the default.