Future imports go after the docstrings

A `from __future__ import ...` statement must go after any docstrings;
since putting them before the docstring means the docstring loses its
magic and just becomes a string literal.  That then causes a syntax
error if there are further future statements after the false docstring.

This fixes issue #203, using the patch provided by @Arfrever.
Use lead blockprocessor comment as docstring

The lead comment in blockprocessors.py should really be a docstring for
consistency with other files.  Fix this with the other part of
@Arfrever's patch for issue #203.
Merge pull request #205 from Gamma3000/future-order

Future statement ordering
Ensure handleAttributes doesn't lose AtomicStrings.

Fixes #204. This was a real pain to debug. But I think the problem stemmed
from the fact that the footnote extension inserted a etree link into the
footnotes last p element. Then when inline patterns are run, the inline code
in that p element is processed. Normally, code would be the first child found,
but with the pre-existing link, that wasn't the case and the parser took a
slightly differant path which would never be encountered in any other
situation. It was this slightly differant path that made the lose of the
AtomicString status of the inline code matter.

Since any AtomicString (including inline code) doesn't need to be run though
hanldeAttributes anyway, we can just skip over it and preserve the
AtomicString. Whew!
Added a note about tox in test suite docs.