Add a hybrid checker for continuation line indentation

PEP8 has some specific recommendations early on which relate to
indenting continuation lines.  Specifically, it distinguishes between
'visual indenting' and 'hanging indents'.  This change implements these
rules, adding several new errors (for now):

 * E120 - traps on a visual indent with hanging indent lines following
 * E121 - traps overly–indented lines inside visual indent regions
 * E122 - catches the evil and wrong indenting default that emacs'
          python-mode applies to 'loose fingernails' (not canonical)
 * E123 - catches continuation lines missing extra indentation when the
          previous line started a hanging indent
 * E124 - catches continuation lines not aligned on 4 spaces; note this
          required a fix to the E23.py test
 * E125 - catches continuation lines with 8 or more space indents
          relative to the previous line without good reason
 * E126 - ensures that indentation leaves blocks visually distinct

All of these errors are directly justifiable from text and examples in
the PEP8 document, and some examples are directly copied from PEP8.  The
exception to this is E122, which the PEP8 standard appears neutral on
but nonetheless I feel is intrinsically related with the rules which are
defined here; to not enforce it would permit multiple valid indent
levels for closing brackets which start lines, leading to ambiguity.
All the PEP8 examples leave the closing bracket on the previous line,
avoiding this question.  This E122 rule agrees with K&R, KNF, Linux,
this VIM auto–indent script:

  http://www.vim.org/scripts/script.php?script_id=974

and the fix to python-mode achieved by the elisp fragment on:

  http://stackoverflow.com/revisions/5361478/2

See testsuite/E12.py for many examples.
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.
Fix an E120 false positive

If there was a bracketed expression closed on the same line
inside a visual indent, the code expected indenting to continue
at the indent level of the last bracketed sub–expression.  To
fix, update the current visual indent level as they are popped
off the stack.
Extend E12* errors to unbracketed continuation lines

If you make a continuation line with a backslash, subject it
to the same rules of how it may be continued.  Of course, PEP8
does say that the backslash is a less preferable form of multi-
line splitting than using brackets.
New continuation line error E127 unnecessary backslash

The continuation backslash is only required if there is not an open
bracket enclosing the end of line.  Make it an error to have it there
anyway.  This broadens the continuation line indenting test to test more
than just indenting, but it is a convenient place to put the test.
Allow tokens following multi–line string literals to avoid E12*

Multi-line literal strings are a little bit of an outsider when it comes
to continuation lines.  If such a token is used, consider the code to be
OK so long as the next token starts either immediately, or at the same
place you'd expect tokens to start again if the multi–line literal
wasn't there.  This is a corner case, none of the examples are
particularly readable, but it shows what does work.
Add checks for continuation line indentation, disabled by default. Closes #64.