Dynamically load api config and refactor the logger

[andreogle]

This branch originally started out for getting the Cloudformation file setup, but I ended up using it for refactoring the config files based on the discussions. This work can continue separately.

Changes

1. Removes logger from both config files in favour of env variables
2. The api package will now dynamically fetch and cache the logger based on CONFIG_SOURCE. The data-pusher will follow the same pattern later.
3. Makes the logger usage consistent in across both packages

Let me know what you think

[Siegrift]

I actually quite liked that the logger configuration was specified in the config file, because everything was configured in a single place.

I see the issue of loading file before initializing logger, but it is not a big deal considering we want to exit the app when config loading fails.

[Siegrift]

@andreogle I've made two notable changes.

1. Fix TS configuration by removing composite which resulted in outdated TS cache. The composite build is setup on Airnode, which is much larger and we don't need such setup here.
2. Improve validation around the ENVs. We want to fail asap when the user supplies invalid configuration. This is done by flowing the ENVs through zod schema. This way, we also get the ENVs in a more typesafe way (and can apply defaults). Using the loadEnv should be used everytime you need some ENV from process.

I will document the configuration in #56