Refactor API Keys

[gabrielfior]

When working on the repo for the Giza agents (https://github.com/gabrielfior/giza-omen-agent), I noticed the order of imports was important when importing PMAT, if one needs to use a custom GNOSIS_RPC_URL (or any other .env).
This is the case because, once PMAT is imported, it sets GNOSIS_RPC_URL using this.

In my head, this is not the desired behavior.
2 things come to mind:
-> Make .env loading lazy, i.e. only on the first time they are accessed, one tries to read from the .env file. Downside is that the application might start and only midway through execution we realize that an environment var is missing.
-> Apply the Singleton pattern into the APIKeys object, so that the ENV is only read once (on demand) and then cached inside one single object.

@kongzii I remember you had some thoughts? Please add them below.

[kongzii]

Using os.getenv is a bug/mistake, probably before we switched to pydantic's BaseSetting (APIKeys) or I just didn't realise it while writing that line of code, sorry.

GNOSIS_RPC_URL can be defined inside of APIKeys and then order of imports won't matter, because it will load .env file automatically. os.getenv doesn't and that's why the order is important now.

Seems to me that the two proposed solutions wouldn't solve this problem:

1. Loading .env lazily --> not sure what do you mean here, like monkey-patching the os.getenv to load from .env file automatically? Sounds unnecessary, we can just use APIKeys.
2. APIKeys as singleton --> this doesn't fix the fact that os.getenv won't read env variables from .env file.