Add a lock for folks using threading. Mucho helpful.

I can't see any *downside* to including a lock here. Basically, it
just says that two threads running in parallel can't touch the code
between the lock.acquire() <--> lock.release() statements
concurrently. We use it in low-level util functions to prevent
concurrent file reads/writes.

This was a bug that showed up while running our auto-documentation
examples.
Move around locks and do a better job ensuring paths exist.
Merge pull request #121 from plotly/andrew-lock-file-read-write

Add a lock for folks using threading. Mucho helpful.
This is an incomplete fix, but a reasonable one for now.

Basically, mpl has its own datetime system, where it uses floating
point versions of the Gregorian calendar days. My attempt to use
ISO formatted date-time strings failed. Therefore, I'm actually
manually formatting the time-string based on epoch time after
converting from mpl_date -> epoch time. Whew!
Add support for barcharts with x-axis date data.
Assume utc time for all dates. This is strictly correct (see below).

Matplotlib's docs state:
'objects are converted to floating point numbers which represent time
in days since 0001-01-01 UTC, plus 1.'

We convert to epoch time with mpl, so it's safe to assume we've got
utc time!

http://matplotlib.org/api/dates_api.html#module-matplotlib.dates
Currently, username matches are case SENSITIVE (not sure why).

Might as well make our tested usernames exact matches.
Merge pull request #123 from plotly/andrew-fix-tests

Currently, username matches are case SENSITIVE (not sure why).
Merge branch 'master' into andrew-fix-mpl_dates
Merge pull request #122 from plotly/andrew-fix-mpl_dates

This is an incomplete fix, but a reasonable one for now.
version bump -> 1.2.9 (thread lock and mpl date fixes)
Merge branch 'master' into etienne-factories