Eliminating contextmanager based transaction-handling
To close #8277

General comment: is the added complexity in the PandasSQLTable (not fallback! so the one based on sqlalchemy) worth it? (has it added value?) 
Because the committing/rolback is something that sqlalchemy can do for us (as it did). So another option would be to leave it as is in PandasSQLTable and only adapt it in PandasSQLTableLegacy? 

This probably makes it a bit more hacky in PandasSQLTableLegacy, but keeps PandasSQLTable as we would do without having to worry about mysql-fallback-support. And when we remove that support we can just clean up the hack in PandasSQLTableLegacy, without having to clean up PandasSQLTable .
 @jorisvandenbossche I think you are right -- my fix was probably overly-complicated.  Here is another possible approach: we use the sqlalchemy contextmanager for non-legacy mode, for legacy mode we create our own contextmanager using transaction handling methods.  
 That seems like a nice approach!
 @jorisvandenbossche  I incorporated your suggestions .  I also upgraded the requirement for the Python 2.6 CI environment to sqlalchemy 0.8.1 (it was sqlalchemy 0.7.4 previously , which didn't support the `engine.begin()` contextmanager).
Now squashing.
 Are you sure about the version. If I look at that section of the docs for version 0.7, it already uses `engine.begin`: http://docs.sqlalchemy.org/en/rel_0_7/core/connections.html#using-transactions
 Aha, it is added in 0.7.6. Can you change it to that version?

edit: or take 0.7.10, the latest in the 0.7 series
 I can, though for some reason I thought we were standardizing on 0.8.1 ... no?
 In any case, I changed the requirement to 0.7.10
 For now, the 7 series was still supported (tested for), but you are right that the docs state 0.8.1. Maybe we should change that.

OK, I will merge when it is green!
 @artemyk thanks!
