This change also exposed a problem in the Cucumber tests with isolated mode,
so I have fixed the tests to handle separation of currently active version
and the default version of a candidate.
Since gvm is now a function that is sourced into the current shell, the old
Cucumber tests no longer work as they try to execute 'gvm' as a process. This
fix instead launches an external bash process for each scenario and pipes the
required commands to it.
A lot of the magic happens in the new BashEnv class which handles the piping
of commands and also managing the output correctly.
This is further work on issue #52.
In order to make version changes only apply to the current shell, I had to make
the `gvm-init.sh` script source the `gvm` one. This meant replacing all `exit`
calls in the latter with `return`s and changing the name of the functions by
prefixing them with `__gvmtool_` (to avoid the functions appearing in bash
auto-completion by accident).
Note that this feature is not enabled by default. The user must create a
~/.gvm/gvmconfig file and add 'isolated_mode=1' to it in order to enable the
feature.
To help with some of the internals, `gvm-init.sh` now exports the `GVM_DIR`
variable if it hasn't already been set by the user. This makes it available to
`gvm` and any plugin scripts that get executed in sub-shells.
`gvm-init.sh` also sources any scripts in `$GVM_DIR/ext` whose name begins
with `sourced-`, allowing users to extend the system with extra functionality
implemented via bash functions. They are required to name their functions with
`__gvmtool_<command>`. Plugins can also be implemented as straight
`gvm-<command>.sh` scripts, but these manually need to source the `gvm` script
if they want access to its internal functions, such as `__gvmtool_help`.
In this 'isolated mode', users need some way of setting the default version of
candidates for new shells. So I have also added a new 'set-default' command
that updates the 'current' symlink to the specified candidate version.
