Client db: Clarify key-value areas
Client db: Clarify key-value areas

Previously I had "scratch" areas that used key-value cells for storage.
The scratch areas were somehow thought for binding text input elements
to them, but that hadn't been defined clearly.

One possibility would be to define them clearly, but I might need areas
of key-value cells in other places. Avoid future duplication by turning
the whole thing into general-purpose key-value areas.

Two considerations:

 - Instead of making key-value areas separate entities I could have
   given each key-value cell an area key. I don't know how that would
   influence performance. Database guys would call it normalization or
   denormalization or something like that. Anyway, I decided to do it
   how I do it now, because conceptually key-value areas feel more like
   separate things to me.

 - I'm not sure whether putting key-value areas in the database is a
   good idea. (1), you can direcly store maps in DataScript. (2), it
   allows me to be sloppy and to not specify precisely what should be in
   the database. As to point 1, I don't know what is better. The other
   side of point 2 is that this way the IDs can be driven by the HTML
   template. This avoids duplication and saves work binding text input
   elements to the database. This might be vain, though, because later
   on I have to refer to them literally again.

Krch, questions, questions. If only there was someone to tell me what is
right and what is wrong.

rmoehn/theatralia