Class names that comply with the CapWords naming convention described in
PEP 8 (http://www.python.org/dev/peps/pep-0008/) are preferred. See the
recent discussion that included the BDFL's recommendations at
http://mail.python.org/pipermail/python-dev/2009-March/086684.html.

Per those recommendations, the attached patch updates every class to
expose a CapWords name to python:

datetime.timedelta  -->  datetime.TimeDelta
datetime.date       -->  datetime.Date
datetime.tzinfo     -->  datetime.TZInfo
datetime.time       -->  datetime.Time
datetime.datetime   -->  datetime.DateTime

In addition, the old lowercase names are reproduced as derived classes,
the methods of which throw PendingDeprecationWarning, and the docstrings
of which advise using the new CapWords class names. The test_datetime.py
unit test is updated to check for proper functionality and for the
presence of the pending deprecation warnings. (This patch relies on the
previously-submitted refactoring patch attached to Issue 5520,
http://bugs.python.org/issue5520.) Various other tests and support files
are updated to use the new CapWords class names.

The current patch still fails one test in test_datetime.py, due to
previously-existing Issue 5516, http://bugs.python.org/issue5516.

This patch includes no documentation updates.

Please don't do this. We need stable APIs. Trying to switch the entire
community to use CapWord APIs for something as commonly used as datetime
sounds like wasting a lot of cycles with no reason except the mythical
"PEP 8 conformance". As I said, it's a pity we didn't change this at the
3.0 point, but I think going forward we should try to be more committed
to slow change. Additions of new functionality are of course fine. But
renamings (even if the old names remain available) are just noise.