Add token creation/list/revocation DB, API and UI

[jkeiser]

This adds the ability to create, view and revoke tokens through the auth UI. It also adds an auth tokens table to the database, and auth api endpoints to manipulate them.

Note: The UI is not fully in sync with @MarkDennard's vision yet, but has most of the shape, and most importantly plumbs all of the data all the way through the system. There are things like dropdowns and spacing and colors that I will be asking people for help for, but it seems worth getting the meat of this feature in and then iterating.

Features

• Auth portal UI!
  • When you go to manage a workspace, there is a new "stack of coins" icon that will take you to the API Tokens page.
  • From there, you can create a token and then get a big wall of text telling you to copy the token NOW NOW NOW for a LIMITED TIME ONLY on SUNDAY SUNDAY SUNDAY.
  • You can view all active tokens. (Caveat: this view shows expiration dates but does not visually distinguish expired tokens.)
  • You can revoke tokens, removing them from the list and making them unusable. (Caveat: SDF doesn't do the check to see if the token has been revoked yet--but the machinery is all there for a followup, and all tokens you revoke now will be denied after that happens.)
• Auth API endpoints to create, list, fetch, rename and revoke tokens.
• A new table in the authentication database to track revocable auth tokens

Code

Vue-wise, there are a couple of little neat things:

• This uses vueuse's useAsyncState composable to reactively track async operations. It is particularly neato for actions: you call createAuthToken.execute() and it will trigger an async function to start. This can probably be more compact, but I was trying to see how far I could get with (mostly) existing APIs and (mostly) avoided the temptation to write a bunch of my own. (OK, I might have written a bunch of these APIs myself and then removed them when I found a way to use existing stuff. But if it's not in the PR, it never happened ...)
• Regardless of this async state stuff, API calls are debounced normally, using our normal API store stuff with new ApiRequest in actions. This interestingly made the authTokens store "headless," in that the page itself does all actual state tracking and uses the authTokenApi. I'm still thinking through the pattern, but for situations like this where we don't want to persist the data forever, it seems to localize stuff and make it a bit more concise.
• Added a new <LoadStatus> widget provides a "loading" / "error" / "success" view based on an asynchronous operation. It has neat stuff with named slots, too. I haven't plumbed it everywhere it could be used yet, but I've put it in several places. The existing components support ApiRequestStatus; I expanded it to support useAsyncState as well.
• Factored a bit of the WorkspaceDetails page into a WorkspacePageHeader widget. I think there's more we can do here; there's a lot of stuff we could consolidate still, particularly around keeping state fresh.