Specs should run in an embedded runtime

[jkutner]

Right now, the specs run in the same runtime as guard itself. This really only causes problems when running guard-jruby-rspec against itself! But it would be best to run the specs in an embedded RedBridge runtime.

[nilbus]

I did some experimenting with jruby-sandbox. It creates new Ruby VM instances to run code in, which is exactly what we want. There were several problems with this approach:

1. As of right now, Ruby VMs cannot be cloned. See my conversation with enebo at http://logs.jruby.org/jruby/2013-05-20.html. It may be possible someday, but not yet. This means that we would need to spawn new a Ruby VM for each spec run.
2. In my tests, the new Ruby VMs never got garbage collected. Each run makes a new copy of the app under test, which is another step toward filling the heap. It consistently took 5 runs with my Rails app, and I got out of memory errors. This is because the Rails threads keep references to the environment. If we just send a Kernel#exit to the VM after each run, this probably would go away.
3. Even if we get GC working for Ruby VMs, we have end up having to wait for the rails startup time before every run. We could start some before our runs like spork and drip, but then this project's approach is no different and just as slow as using guard-spork and guard-rspec.

I think we need to wait for VM cloning to become a possibility.

[jkutner]

As long as we restrict the guard-jruby-rspec code to classes under Guard::JRubyRspec, and we're not for example monkey-patching String, i think running them in the same runtime is okay. It's kind of like how Rspec is loaded when you are running rspec -- it's there but doesn't affect you.

[nilbus]

Mostly it's fine. I have a feeling that if there are any big issues, my team will come across them as we start using this.