Rethink the ArtiPath charset

The following discussion from !1722 (merged) should be addressed:

• @Diziet started a discussion: (+1 comment)

  If an ArtiPathComponent can contain . then I think the leafname can contain two (nonconsecutive) dots. Are we OK with that? I think it's undesirable. It might be misunderstood as nested file extensions along the lines of .tar.gz.

  If we do keep . allowed in ArtiPathComponent, then: this restriction is, I think, strictly speaking, not necessary. . is MIDDLE_ONLY so cannot occur at the start of a path component (and we can rely on accurately identifying path components, because we forbid any of the non-canonical path separtors and unicode stuff that might confused broken systems like Windows).

  I was thinking about the allowed character set. If I want to impl KeyDenotator for IptLocalId (which I probably do) then ideally that would be a high-density encoding. The natural idea would be base64 but: 1. we might be running on a system with case-insensitive filenames 2. the characters available are rather odd: I need alphanumerics plus two punctuation and I have just suggested excluding ..

  It's tempting to say that Unix users shouldn't be afflicted with longer filenames for the convenience of Windows and Mac users, but: that would involve the pathnames depending on the keystore's filesystem. And what if you copy a keystore via a vfat usb stick?

  The case-insensitive filesystem issue is one we should probably think about before we commit to all this. One approach would be to declare that a KeyDenotator may only contain lowercase letters. I guess things like the IptLocalId would use base32.