👌 IMPROVE: Generalize environment for using different shells

[GeigerJ2]

I recently stumbled upon an issue while trying out a few different setups. Actually don't fully recall now how I got
there, but what was happening was that after creating new projects with aiida-project create and activating them with
cda, my AIIDA_PATH environment variable was still pointing to the global $HOME/.aiida, and, accordingly, new
project-specific profiles were being added to the global config file $HOME/.aiida/config.json.

After some digging around, I realized that the issue was an incompatibility between my main shell (fish) and the fact
that I was occasionally launching and using bash. To be precise (and as I have recently, painfully learned),
environment variables of the parent shell cannot be set from a Python subprocess. Thus, in aiida-project, this is
instead handled via the cda command, which, apart from changing the directory, also sources the Python activation
file, activate.fish for fish and activate for bash when using venv. Importantly, aiida-project adds the
command to set AIIDA_PATH to this activation file, e.g. for fish in $HOME/.aiida_venvs/<project>/bin/activate.fish:

set -gx AIIDA_PATH $HOME/aiida_projects/<project>
eval (env _VERDI_COMPLETE=fish_source verdi)

with cda defined as follows:

# Defined in $HOME/.config/fish/conf.d/aiida_project.fish @ line 48
function cda
    source "$aiida_venv_dir/$argv[1]/bin/activate.fish"
    cd "$aiida_project_dir/$argv[1]"
end

Long story short, in my case, cda was pointing to activate not activate.fish, while the command to set
AIIDA_PATH was in activate.

Now, this might be somewhat of a niche case, however, I would propose that we move the location of setting AIIDA_PATH
and the eval statement for tab completion to a general, hidden activation file inside the directory of the project.
This change should also be necessary if we want to add conda support, as here the Python environment is not activated
by sourcing an activate file.

Lastly, as it stands right now, the shell is attached to the global configuration of aiida-project, so we could
instead attach it to each project, or, even better, implement a check on the currently running shell, so that seamless
use of aiida-project is guaranteed even when running with different terminal instances and shells (though, not
entirely sure how one would go about implementing that).

[GeigerJ2]

In addition, for me config.json is currently not written in the .aiida folder under $HOME/aiida_projects/<project>. Very strange...