The smart_strong extension has been removed and its behavior is now the
default (smart em and smart strong are the default). The legacy_em
extension restores legacy behavior.

This completes the removal of keywords.  All parser behavior is now modified
by extensions, not by keywords on the Markdown class.

If you have existing documents that use the legacy attributes format,
then you should enable the legacy_attrs extension for those documents.
Everyone is encouraged to use the attr_list extension going forward.

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.

Fixes #257 and slightly alters comment parsing behavior.

Unlike self-closing tags, a comment can contain angle brackets between the
opening and closing tags. The greaterthan angle bracket at the end of the
first block should not be mistaken for closing the comment. Need to actually
check for a comment closing tag (`-->`). If one if not found, then the comment
keeps going (to the end of the document if nessecary) just like in HTML.

That last bit is a slight change from previous behavior, but should be
unsurprising as that's how broswers parse html comments. And as far as
I can tell, more implementations follow this behavior than any other. The
ones that don't seem to be all over the place.

The current implementation was wrong as it also percent encoded query strings
(which should be plus encoded) and calling urllib.quote on the path (and
urllib.quote_plus on the query string) assumes the url is not already encoded.
What if the document author pasted a url that was already encoded? She probably
did not intend for `%20` to become `%2520`. Or did she? It is now clear to me
why many implementation do nothing to urls. Just pass them though as-is. To bad
if they are not valid HTML. HTML authors have to encodee their own urls, so I
guess markdown authors have to as well.