This reverts commit 28c4d4026e1d9389a99d8cd627c96fa360c17fc4.

See #694. The expectation is that IN is primarily recognized as a keyword,
although it acts as a comparison operator. This also matches the definition of
IN in most SQL syntax references where it is listed as a reserved
keyword (PostgreSQL:
https://www.postgresql.org/docs/current/sql-keywords-appendix.html, MySQL:
https://dev.mysql.com/doc/refman/8.0/en/keywords.html, for example).

Python 2.7 and 3.4 are end-of-life. They are no longer receiving bug
fixes, including for security issues. Python 2.7 went EOL on 2020-01-01
and 3.4 on 2019-03-18. For additional details on support Python
versions, see:

Supported: https://devguide.python.org/#status-of-python-branches
EOL: https://devguide.python.org/devcycle/#end-of-life-branches

Removing support for EOL Pythons will reduce testing and maintenance
resources while allowing the library to move towards modern Python 3.

Using pypinfo, we can show the PyPI download statistics, showing less
than 10% of users are using Python 2.7.

| python_version | percent | download_count |
| -------------- | ------: | -------------: |
| 3.7            |  45.36% |      3,056,010 |
| 3.6            |  26.46% |      1,782,778 |
| 3.8            |  12.22% |        823,213 |
| 2.7            |   9.97% |        671,459 |
| 3.5            |   5.86% |        394,846 |
| 3.4            |   0.10% |          6,700 |
| 3.9            |   0.03% |          2,346 |
| 2.6            |   0.00% |             57 |
| 3.3            |   0.00% |             21 |
| 3.10           |   0.00% |              6 |
| Total          |         |      6,737,436 |

Library users who continue to use Python 2.7 will still be able to
install previous versions of sqlparse.

Compatibility shims have been dropped, simplifying the code.

Using pyupgrade, the codebase has been updated to take advantage of
modern syntax <https://github.com/asottile/pyupgrade>.

The wheel is no longer marked as "universal" as it is now Python 3 only.

This patch changes the grouping of AS so that:

  Foo AS WITH bar AS 1 SELECT 2

with no longer be grouped as:

  [Identifier[Foo, AS, WITH, Identifier[Bar AS 1]], SELECT, 2]

but will be grouped as:

  [Identifier[Foo], AS, WITH, Identifier[Bar AS 1], SELECT, 2]

This fixes the parsing of CREATE TABLE new_table AS WITH ... so the
rest of the tokens after AS are parsed the same as a bare WITH.