While we're doing VersionedPolicy, we probably want to take the opportunity to clean up some stuff about how we do certs.

Some thoughts:

• should we namespace certs, like we do attrs? I.e., have cert names like mtn:branch, mtn:author, etc.?
• changing literal cert values is hard (as noted in UsingCerts). This was most notable when trying to rename branches, because literal branch names are tied too closely to branch certs. The fix is not to allow certs to be changed, but to abstract branch names from cert values using VersionedPolicy.
• certs should have ids, like other objects -- so that we can refer to them when necessary. (This is useful for packet commands, for stating which certs should be trusted, etc.)
• perhaps make the cert format basic_io and documented? add a format version number too, while at it (though it's hard to imagine what would change about certs, them just being tuples and all).
• review how we're doing things like formatting cryptographic data to make sure that it's all up to snuff.
• possibly, add "issued by" and "date" fields.
• certs currently state the key they are signed by by referring to its key id. key ids are currently generated by hashing the actual key, plus the key's associated name. In a VersionedPolicy world, key names are no longer intrinsic properties of keys, but can be different over time (and space -- one key may exist in multiple namespaces); so perhaps these key hashes should change.
• combining date/author/changelog certs into a single cert would save a bunch of space and tie the date that someone said something together. (currently there is ambiguity on revs that have multiple date/author/changelog certs in terms of who said what, when). including branch certs into this new big cert might also be a good thing.
• change our invariants so that we simply don't store certs that we can't verify. treat keys as preconditions to accepting certs, just like we already treat revisions as preconditions to accepting certs. don't bother writing out certs that have invalid signatures -- they are essentially malformed data, like a revision without a manifest stanza or the like. this means we don't have to verify signatures at runtime -- expensive! -- but avoids adding all sorts of annoying cache consistency logic.