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.

See #253. Prior to this patch, if any inline processors returned an element
with a tail, the tail would end up empty. This resolves that issue and will
allow for #253 to be fixed. Thanks to @facelessuser for the work on this.

As we chnaged the order in import trys for short names extensions
(no dot syntax), an extra test was added to the import code for the
occassion when a naming conflict exists. For example, if PyTables
is installed (module name is tables) and the user tries to use
the short name 'tables' instead of 'markdown.extensions.tables'.
Fixes #341.

Of course, this code will get ripped out when the old behavior is
fully deprecated.

The new option parser assumes bool values if the default is bool or
None. As the "title" option is not a bool value, it should default to an
empty string rather than None. Fixes #347.

Fixes #340. The "inline" TreeProcessor runs before the "prettify"
TreeProcessor, but the "smarty" TreeProcessor (wich is just another
instance of `InlineProcessor`) runs after the "prettify" TreeProcessor.
The problem was that the "prettify" TreeProcessor was losing the
AtomicString quality of the text of code blocks (any operation
on a string creates a new string. When that string is an AtomicString,
the new string must explicitly be declared as an AtomicString.
As the "prettify" TreeProcessor cleans up newlines on code blocks,
it was changing the AtomicString to a normal string. And as
`InlineProcessor` identifies what elements to skip solely by whether
the text is an AtomicString, the "smarty" instance was running on
code blocks.

Importantly, I added a test of code blocks and spans for smarty,
so this shouldn't break again.

The builtin extensions will no longer get special treatment and have
the path ("markdown.extensions.") appended . The same applies for
"mdx_" extensions. All names extension must provide the full path.
Fixes #336.

Also deprecating support for passing in extension config settings
as part of the string name. The extension_configs keyword should
be used instead. Fixes #335.

Also raising PendingDeprecationWarnings for positional args or the
"config" keyword on the Extension Class. Pass each setting as a
seperate keyword instead.

Docs and tests are updated. Still need to update extension API docs.

`'path.to.module(option=value'` => `path.to.module.Class(option='value')`
This is in anticipation of #335

The last few extensions were updated to accept dicts/**kwargs as configs and more
tests were updated. Also updated extra to actually accept configs.

Note that extra requires an extra level of dicts. First you need
to indicate tha the settings are for extra, then, which extension
extra wraps. I'm not crazy abount this, bit not sur ehow else to do it
without making all the configs a global attribute on the Markdown class
to that any extention can access any other extensions config settings.
I don't think we wnat to do that.

Also updated extra to use dot notation for the sub-extensions.

All named extensions now use python dot notation in the tests - including
all builtin extensions (eg: 'extra' => 'markdown.extensions.extra'). This
is in anticipation of #336.

Note there are a few tests (in the error tests) that will still need
updating, but not till we make the change as they will test for the
new error message.

If you were to import the class like this:

    from path.to.module import SomeExtensionClass

Then the named extension would be the string:

    "path.to.module:SomeExtensionClass"

This should simplify loading extensions from the command line or
template filters -- expecially when multiple extensions are defined
in a single python module.

The docs still need updating. I'm waiting to update the docs after
implementing #335 and #336 as that will require a major refactor of
that section of the docs anyway.