Make handling of date format strings more robust (closes #1206837).

Make handling of date format strings more robust (closes #1206837).

::Problem:
  If the "dbtimestamp" PI has words in it that contain any of the
  single-letter characters used as date/time formatting
  instructions, the output is not what would be expected.

  For example, Spanish "long" dates look like this:

    23 de mayo de 2005

  So you would expect that you could generate a date of that form
  using the dbtimestamp PI with a format string like the following:

    <?dbtimestamp format="d de B de Y"?>

  But if you try that, you get the following output:

    23 23e mayo 23e 2005

  That is, the "d" in "de" is replaced with the day of the month.

::Cause::
  The format-string parsing logic works by walking through the
  format string character-by-character. So when it gets to the "d"
  in "de", it has no way of discerning that it is not the "d"
  formatting instruction but is instead part of a word intended to
  be included in the output as a literal string.

::Fix::
  The format-string parsing logic now splits format strings into
  tokens and delimiters and evaluates them token-by-token instead
  of character-by-character.

  For example, it splits the Spanish "long" date format like this:

    <token>d</token> <token>de</token> <token>B</token> ...

  Thus, in looking for the "d" formatting instruction, the "d"
  token matches but the "de" token does not.

  As delimiters, it recognizes the following characters:

    <space> <tab> <CR> <LF> , . / - ( ) [ ]

::Affects:
  This change affects output of the "dbtimestamp" PI as well as
  output from any customization layers that call the
  "datetime.format" template. It affect all formats (HTML, FO, etc.).