Introduce a more granular, site-based allowlist

[bcspragu]

This PR updates the allowlist in a few ways:

1. Move from a comma-delimited list of domains to a structured JSON-formatted file
2. Adds support for allowlisting individual emails, in addition to domains
3. Adds support for allowlisting an entity (domain or email) for only a specific set of sites

It also removes the allowlists from the repo, as those will start containing more individual information.

[gbdubs]

My only concern here is on removing the allowlist config from the repo - it just creates a pain when cloning etc. I know we removed sops as a dep from this repo in #8, but this smells off. Could we move the allowlist into the place that we pull the secrets in from? Could we make the allowlist nonsensitive in some way?

[bcspragu]

My only concern here is on removing the allowlist config from the repo - it just creates a pain when cloning etc. I know we removed sops as a dep from this repo in #8, but this smells off. Could we move the allowlist into the place that we pull the secrets in from? Could we make the allowlist nonsensitive in some way?

I originally planned on doing this in this PR, but I decided I'll do it after, it'll look like this:

1. Re-introduce sops (e.g. add a .sops.yaml, create relevant Azure KMS keys)
2. Encrypt the JSON files
3. Update the local test scripts (and any deployment stuff) to decrypt things as part of packaging/running/deploying

There's just a bunch of pieces there, so I figured I'd split it out. Thanks for keeping me honest!

[bcspragu]

(ping for actual approval when you get a chance! this is implemented in #16)

[gbdubs]

Thank you!!