BLD: Cut Travis-CI build times by 30-50%
 and some travis.yml cleanups after recent bug fixes by the travis guys.

just perusing Travis docs

do we have fast finish set?

we could create a build(s) that is allowed to fail (not because we expect it to fail but because it would take more build time)

possibilities:  

2.7 with numpy dev, plus no versioning of most packages so they get the latest releases
the wheels are not useful here (maybe exclude scipy/bottleneck as it takes a long time to build)
thinking latest of tables/Numexpr/dateutil/pytz things that have suprised in the past

python 3.4
 What's the benefit of an allow-fail in that case?
The only issue is the 5 concurrent build limit on travis. If we add one more build, we might
as well add 5 more.
Kepping iterations fast really matters. a 25 minute build (we've been there, before wheels),
means a DOC commit could mean the following one could take 50 minutes to green. 
You might add the additional builds only in the run up week or two to a release. That would
be quite a good thing. If you want to add more regardless, that's ok too. I might grumble
ocassionally, no more.

cc @cpcloud , some numexpr wheels are missing, If you get a chance...
 Finally. 
 48 min -> 26 min

:winning:

and nice to finally see green days are here again. I thought we'd never get rid
of those bogus network errors.
 awesome!
 Reinvesting the time gained into extra coverage actually makes a lot of sense.
We were in an ok place before this (~10min), if we can stay there with more covered 
that'd be good.
 in 0.14 would be prudent to have an sql heavy build
for various flavors (to the extent we have specific code ) eg SQLite , Postgres 
 Very true. We need to sql special attention in 0.14.
