do not set meaningless contributor category in web page

per default it useses indexeddb storage

Modify jIO API to keep user data not modified.
jIO.get({"_id": "foo"} -> jIO.get("foo")
jIO.remove({"_id": "foo"} -> jIO.remove("foo")
jIO.post({"title": "bar"}) -> jIO.post({"title": "bar"})
jIO.put({"_id": "foo", "title": "bar"}) -> jIO.put("foo", {"title": "bar"})
jIO.getAttachment({"_id": "foo", "_attachment": "enclosure"} -> jIO.getAttachment("foo", "enclosure")
jIO.removeAttachment({"_id": "foo", "_attachment": "enclosure"} -> jIO.removeAttachment("foo", "enclosure")
jIO.putAttachment({"_id": "foo", "_attachment": "enclosure", "_blob": blob} -> jIO.putAttachment("foo", "enclosure", blob)

Add jIO.allAttachments method.

jIO.get does not return an _id and _attachments attributes anymore.
jIO.get now really returns the document as saved by jIO.put/post.

and in any case, do not accept deleted ones

Because it is breaking the accessors

Race conditions are likely to happen with CMFActivity between message tables
are automatically upgraded during bootstrap.

Most code is moved from DA patch to ZMySQLDA.

For even more refactoring between SQLDict & SQLQueue,
which now uses SQL tables with the same schema.

The action to recreate activity tables while preserving existing messages
was unsafe for 2 reasons:
- if any error happened, messages could be lost
- it relied on Message.reactivate

Which this patch, any instance created after commit d881edd1 (Aug 2010) will
upgrade successfully. For older instances, make sure you have no activity left.

For cases where 'ALTER TABLE' would not work, a better way to implement repair
functionality would be:
- one action to backup all messages in ZODB
- and another to restore them
And maybe a security so that during the backup-clear-restore sequence,
activities can't be created nor processed.

If any column is added in the future, it would still be possible to write code
that fills them by inspecting messages.