Add Administration, starting with accounts

An account whose Stalwart role manages accounts now finds Administration in
the account menu. It lists, searches, creates and edits accounts -- display
name, other addresses, role, storage limit -- sets a new password, and
deletes, each offered only when the role holds the matching permission.

The server keeps the permissions list from GET /api/account, which it
already called for the edition and threw the rest away. Everything else is
JMAP x:Account, x:Domain and x:Role calls through the existing /api/jmap
proxy, so nothing new is stored and Stalwart decides every call.

Stalwart checks a grant against the caller's permissions but not a password
change or a delete, so an account that outranks the viewer is shown
read-only. Your own password is changed in Settings, which re-seals the
session; changing it here would strand it.

The mock server gains a directory behind the same permission names, with
MOCK_ROLE choosing admin, tenant-admin, helpdesk or user.

68 new strings, translated in all nine catalogues; strings falling back to
English stay at 16.

server/src/app.ts

@@ -824,7 +824,7 @@ function appPasswordName(c: Context): string {
   return `${config.appName} (${browser})`;
 }
 
-function sessionExtras(session: LiveSession, info: AccountInfo = { locale: null, edition: null }) {
+function sessionExtras(session: LiveSession, info: AccountInfo = { locale: null, edition: null, permissions: [] }) {
   return {
     ihasmail: {
       appName: config.appName,
@@ -838,6 +838,11 @@ function sessionExtras(session: LiveSession, info: AccountInfo = { locale: null,
       userLocale: info.locale,
       /** What the upstream server would tell us about itself. */
       server: { edition: info.edition },
+      /**
+       * The account's permissions on that server, so the client can offer
+       * administration to those who have it. Stalwart still decides every call.
+       */
+      permissions: info.permissions,
     },
   };
 }