[activate.tmpl.sh] Gracefully handle when the bin dir disappears

[sw-square]

This PR updates update_hermit_env to handle the case when the bin directory disappears:

Before every command, hermit's update_hermit_env function interacts with ${HERMIT_ENV}/bin a few times (eg checking to see if it was modified, executing the ${HERMIT_ENV}/bin/hermit function, etc.) However, if either of these are missing, it causes noisy errors:

hm🐚 /tmp/hm % mv bin bin2
usage: date [-jnRu] [-I[date|hours|minutes|seconds]] [-f input_fmt]                                                                            
            [-r filename|seconds] [-v[+|-]val[y|m|w|d|H|M|S]]
            [[[[mm]dd]HH]MM[[cc]yy][.SS] | new_date] [+output_fmt]
update_hermit_env:4: no such file or directory: /tmp/hm/bin/hermit
update_hermit_env:5: no such file or directory: /tmp/hm/bin/hermit
update_hermit_env:6: no such file or directory: /tmp/hm/bin/hermit
hm🐚 /tmp/hm %

While during normal usage, the bin directory shouldn't disappear, I've encountered it multiple times personally (eg swapping between different git branches, before and after hermit as added to the repo, or even just accidentally moving the bin dir.)

This PR fixes this by checking to see if ${HERMIT_ENV}/bin/hermit exists before running the rest of update_hermit_env; If it doesn't it calls deactivate-hermit to disable hermit. However, _hermit_deactivate (called by deactivate-hermit) also uses ${HERMIT_ENV}/bin/hermit as well. So this also had to be changed to default to the system-wide hermit if needed

[sw-square]

Not entirely sure about this line:

1. Are these the right defaults if the local ${hermit_exe} doesn't exist? i.e. should it first check for $HERMIT_EXE and then $HERMIT_ROOT_BIN?
2. Should we handle the case where $HERMIT_ROOT_BIN doesn't exist, or is that expected to always be there?
3. Are there reasons to just not even use defaults in the first place? Should we just skip the (new) line 28, and on 27 just print $HERMIT_ENV if $hermit_exe doesn't exist?

[nickajacks1]

2: Yes please! I don't set HERMIT_ROOT_BIN, so this is what it looks like when I nuke the bin folder with this PR:

~/source/hermit$ mv bin/ bin2
Command '' not found, but can be installed with:
sudo apt install mailutils-mh  # version 1:3.14-1, or
sudo apt install mmh           # version 0.4-4
sudo apt install nmh           # version 1.7.1-11
sudo apt install termtris      # version 1.3-1ubuntu1
Hermit environment  deactivated
Command '' not found, but can be installed with:
sudo apt install mailutils-mh  # version 1:3.14-1, or
sudo apt install mmh           # version 0.4-4
sudo apt install nmh           # version 1.7.1-11
sudo apt install termtris      # version 1.3-1ubuntu1

It tries to execute '', which gives these confusing command-not-found messages (on Ubuntu).
If deactivate-hermit can't find a hermit executable, there's not much it can do, but perhaps a little message warning that it couldn't cleanly deactivate would be helpful.

3: Using HERMIT_EXE and HERMIT_ROOT_EXE as backups makes sense to me, but if they aren't found, your idea would fix my issue I mentioned above.

[jvmakine]

I don't think we expect people to have HERMIT_ROOT_BIN so we probably need to deal with it missing as well

[alecthomas]

I think we talked about this in Slack, but would you mind adding an integration test for this to integration/integration_test.go?