Env / config package

[goastler]

Package to automatically load config/env into a known ts type using zod (soon to be our custom parser).

At the moment, there's 4 ways to load config/env:

1. .env
2. config.json
3. config.js
4. config.ts

option 3 exists because ts has to be compiled down to js before being imported dynamically, so I've exposed it as a config type. We could hide this though, to enforce ts usage.

The issues surrounding this PR are:

• terminology: env or config? I'm leaning towards the latter atm
• types
  • .env and config.json cannot load complex data types (e.g. objects) whereas anything in js/ts easily can. At the moment, I've enabled zod's coerce option to go from strings to numbers/bools, etc. However, this doesn't work for objects / arrays. So if you have a complex config type, .env and .json configs cannot be handled. The crux is .env / .json files declare string->string key value pairs, whereas .js/.ts can declare almost anything. If the config type is anymore complex that strings/bools/nums, .env and .json are too restrictive. However, it's super-nice being able to load any kind of config via js/ts!
• usage of process.env - I've made this optional and off by default. We shouldn't chuck everything in process.env, it's a global var and gets bloated easily, only allows string typed values, yada yada. We should just pass a typed config object around
• usage with docker - atm we can pass all our env vars through to docker imgs easily. Less so with config files, we'd have to mount them as a volume. Not a problem locally, but on flux more so!
• confinode - I looked at this, but it has it's own method of declaring types which is similar to zod. I don't think we need yet another way of parsing things, so I don't think it adds much more than natively supporting yaml/json/js configs out-of-the-box
• js/ts configs are dynamic, we can add code to them to do stuff before producing the config, similar to what we do with rollup/vite configs. Not sure this is helpful right now, but it's a nice to have
• .js/.ts configs add a dynamic import into the mix - could not play well when compiling in cjs/esm but yet to test this out
• .ts configs require a dependency on the typescript package (~32Mb unpacked) due to compiling ts to js before dynamically importing. Imo this is a large con of this approach, as anything which uses this package would then depend on typescript. Not sure how that would affect bundling

Future extensions:

• yaml / toml / - just import the interpreter and voila