Fix non-padded month parsing for ISO-8601. Also added test.

[tersers]

No description provided.

[tersers]

Weird, these ran fine on my machine. Will fix!

[tersers]

Fixes #286

I noticed a documentation issue in the parsing/__init__.py's COMMON regex, where it mentions support for dash-separated dates but does not implement it in the regex. This was corrected and elaborated on with other examples, and the regex was changed to support dashes.

[sdispater]

I am pretty sure the ISO-8601 spec does not allow non-padded months: https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates

[tersers]

Agreed, which is why the change is reflected in the common parser rather than the ISO-8601 parser. I understand the user could unwittingly provide an incorrect ISO-8601 string which would fail to be parsed by the ISO-8601 parser but processed just fine by the common parser. If there is a mechanism to strictly enforce ISO-8601 parsing then this commit increases the flexibility of the rest of the library without harming ISO-8601 compliance.

As an aside, I notice an unnecessary print in my commit. I'll remove it later tonight.

[jamesmyatt]

How do you know that "2011-8" means August 2011 rather than 8 Jan 2011?

[tersers]

As you would expect, there's no clear distinction between the two. However, there is some freedom since this string is handled by the common parser.

With that said, another question comes to mind: how much flexibility does the common parser have, and is there a way to specify strict ISO-8601 parsinig or common parsing?