Fix continuation lines false positive on indented blocks

A block which started at an initial indent followed by a hanging indent
would not work due to an array being badly primed.  Fix it, and while
we're fixing small things, remove some breakpoint/debugging code and an
overly long line.
E12: eat your own dogfood: visual or hanging indent, pick one

The ultimate goal and test of any automatic PEP8 test is that of
readability: the check should detect a large number of un–readable, or at
least potentially confusing blocks, and when it fails there should be an
obvious alternate form to switch to which is more readable, or at least,
no less readable, and not awkward.  That way, the net effect of the
stringency is positive, and it is more likely that seasoned developers
whose opinion on code readability is the most valuable will get behind it.

Here, the new E12 test is applied to the pep8.py file itself, and each
modification discussed in more detail in order of incidence.

In the first hunk, a long list of string tokens follows an opening bracket;
and this is one situation where this form is actually quite readable.  This
form can easily be translated into hanging indent by just moving the tokens
onto the next line.  This is a relatively neutral transform; both the
before and after are similarly readable.  The code will accept the closing
brackets at the end of the list, or flush left on the following line, which
I decided looked better for this block.

Next is an if block with parentheses: the visual indented block
unfortunately coincides with the following block (because len("if (") == 4)
and so the following block is not visually distinct; so this change
improves readability by making the "return" statement stand out.

Next up there's an if statement where the continuation line has been
manually indented such that two repeated set of symbols line up and the
difference to their argument value is apparent.  A page is taken from the
GNU style guidelines and an extra pair of parentheses added to permit the
indented visual indent.  This also satisfies another PEP8 recommendation,
which is to put operators before a line break rather than after.  However,
overall this change is quite neutral.

Later in the compound_statements() check there is another if statement
which has E126 again, but also wants to align the tokens on two of the sub–
expressions.  The last line of the statement has plenty of room to move,
though, and gets the permitted extra 4–space indent to separate it visually
from the previous line, improving readability.  The first new test in
E12.py contains two suggested layouts if such a line is not available.

Next up there is a print statement which uses the % formatting operator.
Because this operator typically starts with a long token, and then wants a
list, it can tend to lead to awkward visual indents on a narrow margin.  In
this case the long list of variables was only 2 characters too long, and so
the author outdented it slightly.  As shown, switching to a pure hanging
indent form gets up out of the tight spot (and usually does for problems
like this).  A better solution for the % operator is to use .format(),
which offers vastly improved readability, as demonstrated in the second new
test in E12.py.