Proposal: deploy w3console and/or w3admin in one of the stacks in this repo

[travis]

Context

As part of #194 we've moved the webpages used for email verification into this repository as one-off Lambdas. This works for now but is less than ideal:

1. this requires us to teach this entire repository about JSX (adding preact as a dependency, configuring typescript, ensuring the SST build process knows about it, etc)
2. this moves UI/UX concerns into this repository that is otherwise mostly about infrastructure
3. this encourages us to use different UI/UX tools for email verification than the rest of the UI
4. etc

Proposal

We should deploy w3admin or w3console in a Lambda (using https://sst.dev/examples/how-to-create-a-nextjs-app-with-serverless.html or something similar) and move the email verification pages (https://github.com/web3-storage/w3infra/pull/194/files#diff-f329cd1c816e36c581a6d2371440f0ef0303c1a4e99499eb766acd56f8c1c0b1 and https://github.com/web3-storage/w3infra/pull/194/files#diff-6b0cdcae75901bb39f2a415475c2e0a4534d2a056e8e1cdccf656877c63aadf9 et al) into them.

Requirements

1. don't break our integration tests (https://github.com/web3-storage/w3infra/pull/194/files#diff-6bb01a9664f0d2819bc4e2290b685dddc6dfb10fd786e7fa30933ae5ec57212b) which currently use the email verification pages to create an authorized client
2. make the email verification link a bit easier to find programmatically (https://github.com/web3-storage/w3infra/pull/194/files/a4c656fb74e22d6b06f24b7483fdcb4ce9132ede#diff-aa2fe06b039bdcc4edb251028fe72ffc5b0f69f318cd51174b89b02ef99b9fafR45)
3. ideally enable all of the interesting Next.js hosting bits (SSR, incremental static regeneration, middleware, etc - in other words, ideally this wouldn't just be a static export) - need to investigate what functionality is available when serving it in a Lambda

### Tasks
- [ ] Decide which webapp we want to deploy and what the scope of that webapp is
- [ ] Implement email verification in that webapp
- [ ] Configure SST to deploy that webapp
- [ ] Enable CI/CD for the webapp (maybe a no-op?)
- [ ] Improve programmatic discovery of email verification link
- [ ] Remove JSX-aware config, preact, etc (review #194 to determine scope)

[olizilla]

re: point 3... I'm kinda into deploying just a static html export where ever possible, and then making sure we keep things snappy by making sure the page resources don't get too big and have sensible caching rules. Keep it simple!

We can opt back in to full magic in the future when we find a need for it. Static html also means we can keep publishing our sites to IPFS...

we've broken the gateway experience for "website that talks to api" hosting, but we could at least keep the fully localhost, i fetched this from my own node experience working... and spare ourselves some infra complexity (nuance: it's still an odd duck, as it would have to talk to our apis, which are not available on localhost, but, maybe, one day)