pgsql: Adjust datetime parsing to be more robust.

Log Message:
-----------
Adjust datetime parsing to be more robust. We now pass the length of the
working buffer into ParseDateTime() and reject too-long input there,
rather than checking the length of the input string before calling
ParseDateTime(). The old method was bogus because ParseDateTime() can use
a variable amount of working space, depending on the content of the
input string (e.g. how many fields need to be NUL terminated). This fixes
a minor stack overrun -- I don't _think_ it's exploitable, although I
won't claim to be an expert.

Along the way, fix a bug reported by Mark Dilger: the working buffer
allocated by interval_in() was too short, which resulted in rejecting
some perfectly valid interval input values. I added a regression test for
this fix.

Modified Files:
--------------
pgsql/src/backend/utils/adt:
date.c (r1.108 -> r1.109)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/date.c.diff?r1=1.108&r2=1.109)
datetime.c (r1.144 -> r1.145)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/datetime.c.diff?r1=1.144&r2=1.145)
nabstime.c (r1.131 -> r1.132)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/nabstime.c.diff?r1=1.131&r2=1.132)
timestamp.c (r1.123 -> r1.124)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/timestamp.c.diff?r1=1.123&r2=1.124)
pgsql/src/include/utils:
datetime.h (r1.53 -> r1.54)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/datetime.h.diff?r1=1.53&r2=1.54)
pgsql/src/test/regress/expected:
interval.out (r1.10 -> r1.11)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/interval.out.diff?r1=1.10&r2=1.11)
pgsql/src/test/regress/sql:
interval.sql (r1.6 -> r1.7)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/interval.sql.diff?r1=1.6&r2=1.7)