If both open and close was not found in first block, additional blocks
were evaluated without context of previous blocks.  The algorithm needs
to evaluate a buffer with the left bracket present.  So feed in all
items and get the right bracket, then adjust the data_index to be
relative to the last block. Fixes #452.

HRProcessor tried to access a member variable after recursively calling
itself.  In certain situations HRProcessor will try to access its
member variable containing its match, but it will not be the same match
that call in the stack expected.  This is easily fixed by storing the
match locally *before* doing any recursive work.

This aims to escape code in a more expected fashion.   This handles
when backticks are escaped and when the escapes before backticks are
escaped.

Don’t allow spaces in image links.  This was also causing an issue
where any text following a space was treated as a title. Ref #484.

The logic for the current regex for strong/em and em/strong was sound,
but the way it was implemented caused some unintended side effects.
Whether it is a quirk with regex in general or just with Python’s re
engine, I am not sure.  Put basically `(\*|_){3}`  causes issues with
nested bold/italic. So, allowing the group to be defined, and then
using the group number to specify the remaining sequential chars is a
better way that works more reliably `(\*|_)\2{2}.  Test from issue #365
was also added to check for this case in the future.

This issue was discovered when dealing with nested inlines.  In
treeprocessors.py it was incorrectly handling tails.  In short, tail
elements were being inserted earlier than they were supposed to be.

In order to fix this, the insertion index should be incremented by 1 so
that when the tails are inserted into the parent, they will be just
after the child they came from.

Also added a test in nested-patterns to catch this issue.

Fixes #253. Thanks to @facelessuser for the tests. Although I removed
a bunch of weird ones (even some that passed) from his PR (#342). For
the most part, there is no definitive way for those to be parsed. So
there is no point of testing for them. In most of those situations,
authors should be mixing underscores and astericks so it is clear
what is intended.

markdown/inlinepatterns.py is now at 99% coverage.

I have no idea why the two remaining lines are not not covered.
I it not clear to me under what circumstances this two if statements
would ever evaluate to True. I'm inclined to just remove them, but perhaps
there is an edge case I'm missing. I'll take another look later.