…on by idea.
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.
This reverts commit e7858acb71b0d338a47203353189abae299f5b6f.