Fix waterfall tooltips and click to restore view

[yuzawa-san]

• the waterfall tooltips were misleading when the view changed. they were only accurate for the current view. the solution is to store the view parameters (center, fft center, span) and timestamp to properly construct the tooltip's time and frequency.
• since that data is now stored, it is pretty easy to restore the view if the user were to click on a point on the waterfall. currently, clicking on the waterfall changes the demod frequency.
• the datapoints are stored in a vector of structs. the same circular buffer implementation that the waterfall image uses is used as well.
• the waterfall used to invalidate when the lookback range changed, but since the timestamp is stored for each row that is not needed. also if the DSP was disabled then reenabled, that would seamlessly keep track of the history (with a discontinuity in the timeseries).
• the only thing which causes the timeseries to invalidate is if the sample rate of the DSP were to change. this is because we cannot faithfully or safely restore the view when a user clicks. fixes #554

[argilo]

This seems like a useful feature.

One bug I've noticed: sometimes if I tune away by a large amount (by adjusting the 100 MHz digit, for instance) and then click on the "old" part of the waterfall, nothing happens. I'm not sure yet why it only fails some of the time.

[yuzawa-san]

i had to reorder the mousePressEvent logic. clicking near the demod frequency or the low/high of the filter box (even in the waterfall) was falling into those first 3 conditions. the solution was to make the click logic only run when in the waterfall and the existing logic run on the overlay region.