Added datetime support

[hildjj]

If you assume that the inbound datetime is UTC, it's not so bad.

[martinkou]

I didn't include datetime support in the beginning because Python's timezone support is a mess. Your patch could work if we do our best to make sure the BSON output is in UTC, and that the deserialized datetime output is also in UTC. If we're unsure about the input or output in either steps, warn the developer. There's no ambiguity as long as the developer is using timezone-aware datetime objects so we should encourage that. I'd suggest a few more changes to this patch...

1. Instead of using time.mktime() and timetuple() in encode_UTCdatetime_element(), use calendar.timegm() and utctimetuple(). This ensures a timezone-aware datetime object would be properly converted to UTC.
2. If the incoming datetime object to encode_UTCdatetime_element() has no tzinfo (e.g. the default output of datetime.now() with no tz), we should warn() the developer about the ambiguity and the developer will have to filter out the warning himself if he's sure he's using the datetime objects correctly. We should most probably create our own warning category class for this case.
3. If possible, I think decode_UTCdatetime_element() should return a UTC zoned datetime object if possible. It's a shame that Python doesn't include its own timezone database. But we can add pytz to the package's dependency list and always return datetime objects zoned to pytz.utc there.