Fix yMaxValue when areaMode=stacked

### Problem

The Y-axis' upper limit may be miscalculated (too large/tall) when timeseries consolidation occurs & that consolidation paves over significant outliers in the underlying data.

This only occurs when viewing the graph with `areaMode=stacked`; all other `areaMode`s are fine.

### Steps to replicate

* Get a time series with more points than you can graph (forcing consolidation) which has at least one or two significant outliers (spikes).
* Graph it with `areaMode=` (i.e. empty); observe that the Y axis reflects the graphed data's max values. [Example](http://f.cl.ly/items/0c3Y3U1w3R3p352M183q/Image%202013.06.05%208%3A42%3A30%20PM.png)
* Switch to `areaMode=stacked`; observe the actual "profile" of the graphed data doesn't change but the Y axis grows, creating (potentially lots of) empty space. [Example](http://f.cl.ly/items/0w1G2z1d361z1W1J183R/Image%202013.06.05%208%3A42%3A09%20PM.png)

### Investigation

The code in `setupYAxis` that determines maximum Y axis, treats the TimeSeries involved differently:

* When `areaMode` is not `stacked`, it obtains the max value across all series being graphed, then gets the maximum of that, resulting in the graph's global maximum.
* When `areaMode=stacked`, it appears to reinvent `zip` (not sure why) using a combination of `len(series)` and `series[i]`.
* With no consolidation, the result is the same for both `areaMode`s.
* When consolidation occurs, a problem:
    * `TimeSeries` inherits from `list`, and overrides `__iter__` to handle consolidation on the fly.
    * But it does **not** redefine `len` or `__getitem__`!
    * Therefore, `len(series)` and `series[i]` operate on the full data set -- but iteration operates on the consolidated data -- leading to the mismatch.

### Solution A: correct but maybe bug-prone

Implement `TimeSeries`' `len` and `__getitem__` (and possibly other missing methods) so they reflect consolidation. This would require caching the consolidated copy of the data whenever `consolidate()` is called, instead of using a generator. Memory impact should be limited: consolidated data sets max out at pixel X-axis counts, i.e. probably <~2000, regardless of actual data set size.

However, this could have wide-reaching effects and might surface bugs elsewhere that rely on the current behavior (?).

### Solution B: safer, limited workaround

Use `itertools.zip` when `areaMode=stacked`. It behaves exactly like the code it replaces (AFAICT) but uses the iterator API to access the `TimeSeries` objects, ensuring it works with consolidated data.

I have implemented Solution B in this pull request, but am open to exploring Solution A if folks agree it's worthwhile.