Previously, the code was ignoring whether this was a new term when determining
whether the currect item should be loose or not. Fixes #243. Thanks for the
report @Anomareh.

Setting output_format must happen after extensions are loaded. Only in that
way can an extension register a serializer so that it will then be available
to be used with the output_format keyword. A test has been added to avoid
this regression from happening again in the future.

Fixes #238, partially reverses commit 41cc055 and provides a better fix for

It is up to the markdown code (and extension authors to make sure tags are
of the correct case (there may be cases were an extension might need to
mix cases - which should be preserved). Fixes #237. Thanks for the report
@eichin.

Like headers (h1-6) dt's can only be on one line, so we need to use
the header regex on dt's. This was implemented after considering a recent
[discussion](http://six.pairlist.net/pipermail/markdown-discuss/2013-July/002859.html)
on the markdown mailing list. Prior to that discussion, I never considered
that it was impossable to set block level attrs on dt's. Now it is.

A header can be only one line - so unlike other block level elements, a
attr_list must be at th eend of the line. To disingush it from an inline
attr_list on the last child in a header, we must require at least one
space before th eblock-level attrt_list.

Always intended it to work that way. Not sure how I missed that before.
At least we're testing for it now.

Not sure how I missed that when committing ea4af0d. Also as a side-effect,
this fixes #230 - which brought my previous oversight to my attention.
Thanks for the report @divisoryang.

Also added some tests - including tests of list items without attr_lists.
Sometimes I forget to test markup that does not use an extension when an
extension is enabled. That's what resulted in #230 being reported.