Handle situations without data

[w33ble]

Closes #1847

Provides a new error type and handling for when there isn't enough data to create a visualization

[w33ble]

Table vis doesn't get any notice about missing data.

Also, apparently this broke some tests :(

[w33ble]

I noticed a weird bug with tile maps on the dashboard, this seems to result from the visualization being hidden.

• Add a query filter that results in no data
• Note message that it can't render anything
• Remove filter
• Note message that the area is too small

The issue is in visualizations/tile_map:

height and width are both -2 since the parent is hidden via ng-hide

Refreshing the view (by hitting enter in the query bar again) will bring it back.

[spalger]

The solution I quickly tried to put in place on Friday was:

• the visualize directive is in charge of displaying errors across the board
• when a visualization can't render properly, it should throw an error
• when the visualize directive receives an error, it should hide the chart and display only the error and the spy

This solution seemed to be working on friday, but after trying to write tests proving that it worked I noticed a flaw: both the vislib and template visualizations need to render asynchronously, and can't always throw their errors to the visualize directive.

Currently, the async rendering is caused by the "resize" event, triggered by the resize checker in the vislib. In the future, I imagine there will be template visualizations that will do async rendering and we should have a good story for those situation as well.

This means that we need to do something different. Here are my two ideas:

1. The visualize directive becomes responsible for triggering all events which will cause rendering. Those rendering methods can still throw errors, or return rejected promises, to cause an error message to display. This will work fine for the vislib, but probably not for the template visualizations which will likely render based on watchers.
2. The visualize directive exposes a controller to the scope which is rendering the vis, and provides a way to pass the errors up. This will work fine for the template visualizations, but not for the vislib since it is not implemented as a directive and therefore doesn't have any notion of $scope or controllers.

1+2=3. as a third option, we could implement both solutions in the respective renderbots, and then have the renderbots communicate the error to the visualize directive. While this is likely to satisfy the requirements we have with a fairly flexible solution, it feels like a lot of work just to implement error handling at a higher/shard point.

Perhaps there is an easier way to implement it, which will work for both the vislib and template visualizations, which wouldn't require a lot of duplicate code?

@rashidkpc @w33ble @stormpython @jthomassie @simianhacker @lukasolson Ideas?