This PR reverts the addition of .envrc from #3745. It also updates the docs to mention how the reverted functionality can be enabled.

Note: I'm open to alternative solutions for this, but I haven't found any good ones.

The motivation behind this change is that direnv has no alternative point of entry than .envrc which means that if we commit an .envrc to the repo, it'll be hard(er) to maintain an .envrc containing personal preferences (due to there constantly being a file in the repo with local changes and you have to be very careful not to commit, could contain secrets and what not).

The motivation is also selfish, to a degree. For me, direnv is a tool to ensure the environment is set up the way I want it to be, and may vary from system to system or project.

There is discussion ongoing in direnv/direnv#556 that would fix/allevate the issue.

Potential workarounds were considered:

• Tell git to ignore changes to .envrc or to never check out the file (after some research, doesn't seem possible)
• Tell direnv to source an alternative file

The latter would be possible to some degree, but has some unwanted consequences, the following workarounds do exist, however:

1. We could add source_env_if_exists .envrc.local to the .envrc in the repo
2. The user can add a hacky workaround to their ~/.config/direnv/direnvrc

Option 1 could work, but the sourced file stays outside the security framework (direnv allow), in theory a malicious author could try to add a .envrc.local to this repo which would lead to arbitrary code execution on any machine that has allowed the original .envrc once the new file is pulled.

Option 1 also has the downside of enabling Nix if it's installed (which may not be wanted), which brings us to option 2.

For option 2 the user could add this to their ~/.config/direnv/direnvrc:

use_nix() {
	echo "direnv: use nix no-op"
}
source_env_if_exists .envrc.private

However, this solution seems janky. Again we're sourcing a file outside the security framework (but at least we can use an obfuscated name, so the above mentioned security implication is mitigated to some defree).

A second observation of this is that .envrc.private will be sourced immediately, so it could still be overridden by values in .envrc. There may also be other side-effects of sourcing in the direnvrc that I'm not aware of.