Activating a different environment while activated leaves unclean environment variables

Given two environments `FOO` (which sets env var `MY_ENV=hello`) and `BAR` (which sets `MY_ENV=goodbye"`):
1. activate `FOO`
2. without deactivating `FOO`, activate `BAR`
3. Hermit prepends `BAR/bin` to `PATH` without first removing `FOO/bin` and creates the environment variable `_HERMIT_OLD_MY_ENV=hello`
4. run `deactivate-hermit`
5. Hermit removes `BAR/bin` from `PATH` and restores `MY_ENV=hello`.
6. **Issue**: we are no longer in an activated hermit env, but we still have `FOO/bin` on `PATH` and still have `MY_ENV=hello`. Carrying artifacts of a previously activated hermit env around could have odd consequences, especially if something like JAVA_HOME is left set.

I assume that keeping `FOO/bin` on `PATH` is intentional for the sake of convenience in nested environments. If that is indeed the case, then one way to resolve this may be to keep a stack of previously activated environments and either:
* change `deactivate-hermit` to only deactivate a single environment (sounds more annoying than useful)
* ensure that `deactivate-hermit` explicitly unwinds all previously activated environments

I also noticed that shell-hooks will always explicitly deactivate environments before activating a new one, making it impossible to encounter this issue.

Start by tracing the activation and deactivation entry points, especially deactivate-hermit and shell-hooks, and reproduce the FOO-to-BAR sequence described in the issue. Compare PATH and environment-variable state before activation, after switching, and after deactivation. Done means the intended nested-environment behavior is defined and deactivation no longer leaves unexplained artifacts.

Written by the indexing model from the issue text.