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`
@gianm and I fixed some inconsistencies related to empty time buckets when buckets at query interval boundaries and maxtime don't line up, see https://github.com/druid-io/druid/pull/705.
It is still not consistent with groupBy, which confuses users (https://github.com/druid-io/druid/issues/701).

Do we need this flag for topN as well?

I believe things would be more consistent overall if we skipped empty buckets by default, since if data is missing for an entire segment granularity, those buckets will be missing anyway, and I don't believe results should depend on segment granularity.
 
I would be in favor to skip empty buckets by default in 0.7, but we may want to make that change as part of a separate PR.