[CT-1765] [Feature] Provide env vars as data during runtime

[jtcohen6]

First investigate:

• [CT-1806] [Spike] Measure usage of certain functions(os.environ, os.path) #6587

---

Goal: Provide env vars as input "data," rather than reading them out of the system during compilation/runtime.

Two thoughts here:

1. Store the saved values of env vars in the manifest (produced at the end of parsing), and read those values out of the manifest to resolve {{ env_var() }} during compilation/runtime, instead of calling os.getenv yet again. We already capture env var values during parsing (saved in target/partial_parse.msgpack), to detect any changes during partial parsing.
   • Exception: "secret" env vars, which we never save, don't handle within partial parsing, and also are only used during parsing to resolve profile + packages config.
2. Allow users to define a dbt.env file, which completely removes the need for system access. Anywhere we currently call os.getenv/os.environ directly, we should instead check the contents of the dbt.env file.
   • For programmatic invocations: ability to skip the dbt.env file, but pass in as an argument during initialization.
   • Related thought: a yaml version of this file, dbt_config.yml, would have a lot of overlap with the UserConfig ([CT-1470] Whither UserConfig? #6207) — all those configs can be defined as env vars, too. For complex configuration, yaml can provide a nicer UX (!), compared to KEY=value syntax.

Our ultimate implementation may want to include either or both (or neither, if there's a third & even better options). The big idea is, no need for os.getenv at runtime, which further unlocks the ability to do parsing + compilation/runtime separately.

[jtcohen6]

Closing in favor of the dbt.env proposal outlined in #6207