Website requirements

Replacing #27 in order to pin this. I want give more context on the pending software design decisions we need to make in order to build out a website (this affects #102 and #103, which are much appreciated!)

## the problem

Entropic needs a website, because:

1. In order to allow people to sign up for accounts, we use GitHub OAuth login for signup and token creation
2. In order to allow people to manage their account, we display a token management UI.
3. In order to aid discovery & vetting of packages, we want to display information about packages (dependencies, dependents, etc.)
4. In order to aid vetting of packages, we want to display information about package contents (styled, rendered package contents as html)

The current website doesn't have any styles, is likely inaccessible, and is hard for developers to extend. Importantly, it's also _embedded into the registry service_, which could present security & caching concerns down the line.

## constraints, rakes in the yard, & open questions

### splitting into services

At present, Entropic runs in a single process. Because certain tasks (like syncing external packages) are too time-consuming to run in the duration of a request/response cycle, we need to split this out into multiple services. Eventually, I believe we'll need 4 services:

1. The existing external registry API service we expose today, talking to...
2. A :sparkles:new:sparkles: internal api encapsulating our data stores that the website, worker, and registry service can leverage.
3. A :sparkles:new:sparkles: external website service talking to that same internal api
4. A :sparkles:new:sparkles: worker service for processing syncing requests, talking to the internal api

For the production entropic instance, @ceejbot took a clever approach with nginx `proxy_pass`'s so that we _can_ simulate privileged APIs for the website to use by mounting them on the registry at non-exposed routes (for example, `/private/`.) This lets us start working on the website _without_ having completed the other two :sparkles:new:sparkles: apis. However, until we split out the website process from the registry process, web handlers will use HTTP clients to talk to internal handlers in the same process. We'll start this process for the registry as well.

This is quite a mouthful: this is all to say that when the website starts needing to get at registry data, please pull in @chrisdickinson and/or @ceejbot.

### Single page app or Server Side Template Language?

We'll want to consider whether we use a server-side templating language like Nunjucks to render pages in a traditional fashion, or go a single page app route using something like React + Next.js. Right now I am leaning towards server side templating using Nunjucks (or similar):

- Our present Oauth & CLI signup needs lean on url routing. (They could, yanno, not. But.)
- Our form needs are pretty basic.
- SPA's introduce a certain level of maintenance complexity (bundling FE assets, etc.) Next solves this pretty nicely, which is one of the (many) things I like about it, but it's still a cost.

I could be wrong here, so please poke holes in this. What are we buying with a single page app?

### CSS

Let us do the simplest thing that works, then iterate. I propose we use Tachyons for a base coat, then specialize with an added stylesheet. (When this gets unwieldy, that's when we should start looking into css-modules or css-in-js as an additional layer on top of tachyons.)