WIP/ENH: add Stockwell transform to time_frequency

[Why you should use the S transform](https://bytebucket.org/cleemesser/stockwelltransform/raw/d87ff20d787d36d5280dcd26cbaf309dcd982bf4/ref/Stockwell-Why%20Use%20the%20S-Transform.pdf)

If you're too lazy to read:

- like a wavelet
- but uses Gaussian windows that absolutetly referenced (to the time window)
- frequency independent amplitude response
- this means you don't have to manually tinker with n cycles etc.
- hence allows for automated TFR analysis
- resolution can be improved using multitaper

This code without MT:
![stockwell_python](https://cloud.githubusercontent.com/assets/1908618/2753433/2cce52c0-c934-11e3-8dfb-746e8f08777f.png)

Original C code:
![tfr_compare_morlet_cwt_strans](https://cloud.githubusercontent.com/assets/1908618/2753440/44574a46-c934-11e3-9663-4c51b00f5594.png)

Original C code + MT:
![tfr_compare_morlet_cwt_stockwell_mt](https://cloud.githubusercontent.com/assets/1908618/2753429/163d93ea-c934-11e3-9ee2-b83d40a55ba4.png)


Todo:

- improve API
- add mulitaper support
- improve speed (is reasonable, but C is still significantly faster)
@Eric89GXL I'm really happy. Waiting 60 seconds for a full sensor layout seems reall fine. Maybe we can do better, I think it's already faster than other options. Maybe we can look into it later. Let's rather merge this, it's been to long up in the air.