Version 1.0: Move to file-based redirect storage

[kristianfreeman]

Currently lilredirector is based on Workers KV storage. This is an interesting and useful look at how quick it can be to spin something up with KV, but it leaves a lot to be desired in a number of ways when it comes to practically and efficiently using lilredirector at scale:

1. Lots of manual configuration that requires intermediate+ understanding of Workers and Wrangler (setting up a KV namespace, adding it to wrangler.toml, etc)
2. No tracking of when a redirect was added, or by whom
3. View counts are useful but inaccurate with KV as it stands -- Durable Objects can fix this but isn't necessarily any better at issues 1 or 2

Moving to a file-based system, e.g. loading in JSON or something similar, will mitigate the above issues. A file can be tracked via Git, easily moved between environments (e.g. in development or production), and will have minimal impact on file size for most situations.

In version 1.0, lilredirector will load redirects from a file as the Worker boots up. This will likely make it easier to support more advanced configuration as well (e.g. regex support as requested in #10), and remove a ton of code for managing the UI and associated API routes for managing these redirects at the edge.

Note that this is like..... a really breaking change. In addition, I'll need to spend some time specifying what the file looks like -- for instance, is it JSON? TOML? YAML? There's a ton of things to figure out here, but in case anyone is interested in the long-term direction of this project, I wanted to document some of this stuff and make it available for discussion.

Side note: there's been some discussion in the Workers discord re: text bindings, which are used for the static asset manifest. Because they aren't supported by Wrangler, I don't think it's the right direction right now, though there's definitely an argument to be made that since we're using something very similar for Workers Sites (using text bindings to map paths to known filenames), it could probably be a good fit here as well. I'd revisit this as an option in the future if Wrangler supports easy management of those values.

[kristianfreeman]

lol, apparently we weren't on version 1.0 yet, so calling this version 2.0 doesn't make much sense. 1.0 it is!