19th April 2004: New (externally parsed) format for lists.

OK, I figured that getting clipcode to parse lists would be tricky
(though I might deal with it in some later version), and it might be
better to just encode a list as a string stored in a single value.

Advantages would be that it'd keep clipcode simple, and there wouldn't
be the vague ambiguity of spreading lists across lots of keys ("is this
key part of a list?"). Obvious disadvantage is it requires a further
program, its own format, and *might* use up more space than clipcode
allows a value to have.

To avoid screwing with other formats or languages (HTML, XML, bash, etc),
I decided not to use (many) metacharacters used by them. Also, as the
format is to be generated and parsed by a program, I figured there's no
extra niceness in having the delimeters being single unescaped symbols,
rather this makes things ickier. If only pairs of symbols are given special
meanings, it's easier to parse IMO. So:
List: Header Body
Header: LEFTDELIM Arity RIGHTDELIM
Body: Record *
Record: LEFTDELIM Field (SEPARATOR Field)* RIGHTDELIM
LEFTDELIM: ^{
RIGHTDELIM: ^}
SEPARATOR: ^,
CARETSYMBOL: ^^
Arity: integer representing number of fields per record
Field: You know what this is

Note that here, ^ is genuinely representing the ASCII caret symbol, and
NOT denoting CTRL. ^ followed by ANYTHING ELSE is translated as "?" as
it is an error. If a "verify" or "validate" type command is given with
a list string containing such a pair, it'll say so.

It's also an error for a record not to have "Arity" fields in it. A field
is considered to take all the space between the delimiters, so in
^{ A spaced  out field  ^, etc ^}  the first field is
 " A spaced  out field  ". See?

NB: In various cases, it'd be easier to just stick a bunch of values in
a file instead. But if you've got maybe a lot of lists, that could get
messy.
