Remove linking unless explicitly enabling testing

[andrewstucki]

@d-unseductable / @malept : So, here's my solution to the discussion in #25.

Basically the idea is to only pass the linkage to libruby when we build ruby-sys with --features=test. It's kind of ghetto that you have to actually feature-flag it, but it looks like that's the only way of really doing that in a build script as far as I can tell. Also, since you literally only need to link libruby when you would want to run Rust tests, I figure there's no real difference in just supporting dynamic linking.

I'll also submit a PR for ruru to re-export the feature flag so that the Rust tests can still be run.

[malept]

Thanks, I really appreciate the amount of work you've put into researching the problem space and implementing a solution.

It seems like a reasonable change (and also means that I can delete a bunch of static-related code from Thermite), unfortunately I don't have write access to either this or ruru, so I can't merge either PR. I would wait anyway until the tests are fixed in master.

[andrewstucki]

@d-unseductable in the meantime I believe I also fixed the travis tests. Basically the OS X images have pip2 instead of pip -- so travis-cargo needs to be installed with that. Also, I removed linking the libraries from LIBS since I believe they are only needed when you link to libruby statically.

[malept]

Hrm, when I get some time I need to write a PR to replace travis-cargo (unmaintained, Python) with cargo-travis (maintained, Rust).

[Antti]

I think this should be made configurable, since there is also a use case, where you want to run a ruby interpreter inside a rust program.
Imagine a rust program, embedding ruby interpreter for some scripting purposes.
It is possible now by just adding this crate, but with this PR, one would need to link libruby manually (or build their own build.rs).