Don't blindly close FDs after fork()

Simply closing FDs > 2 after fork was causing problems on MRI
2.0.0-preview1, which uses a pipe internally to handle signals. It's not
clear why 1.9.3 wasn't exhibiting this behaviour.

Since the FDs that are reserved by the VM may change and because we use
1.9 or later (which support close_on_exec), Urchin now relies on this
rather than manually closing open descriptors. I realise that not all
kernels support this, but I feel that is an edge case that can be dealt
with if the need arises.

Tested-by: Mark Somerville <mark@scottishclimbs.com> [F17, MRI 1.9.3/2.0.0-dev]
Signed-off-by: Mark Somerville <mark@scottishclimbs.com>
Populate URCHIN_INFO env var with git and VM info

Tested-by: Mark Somerville <mark@scottishclimbs.com> [F17, MRI 2.0.0-dev]
Signed-off-by: Mark Somerville <mark@scottishclimbs.com>
Revert "Define Shell.subshell to run a command string"

This method of eval-ing Urchin code in-process was a blind alley. As
well as being mis-named, Shell.subshell was really a way to avoid
passing a Shell instance around.

In the end it turned out to cause more problems that it fixed, such as
the JobTable sometimes now being defined when the subshell received
SIGCHLD.

This reverts commit 92bd0d8a2b8b6aced7f81805ba994af03bf14fb6 as well as
changing any code that depends upon Shell.subshell to use an already
existing instance of Shell.

Tested-by: Mark Somerville <mark@scottishclimbs.com> [F17, MRI 1.9.3]
Signed-off-by: Mark Somerville <mark@scottishclimbs.com>
History: call before_appending_proc with @shell

360c7723 reverted the Shell.subshell facility. This ensures that the
History.before_appending_proc can still evaluate shell commands.

Tested-by: Mark Somerville <mark@scottishclimbs.com> [F17, MRI 1.9.3]
Signed-off-by: Mark Somerville <mark@scottishclimbs.com>