The run_print functions have usability issues

[Matt Jones]

The C# and Java run_print methods are designed to work on files in the same directory. They don't work with programs installed with the normal install methods.

[Matt Jones (workhorsy)]

This problem has exposed the awkwardness of the run_print functions.

There are problems:
1. It is not obvious if it will run the program from the current directory, or the path.
2. C/C++/D programs don't need a runtime like Python, Java, and C#.
3. The runtime languages use a script to bootstrap the runtime when installed, but expect the user to supply the runtime when called from a directory.

[Matt Jones (workhorsy)]

In order to get around this we need to do the following:

1. Make one Helpers.to_native function. Instead of having a to_native for each language.
2. Make one Process.run_print function. Make sure to stress in the doc that you will need to do ./ before running a local program for this.
3. Make a Language.runtime_run_print function for each function.

[Matt Jones (workhorsy)]

We need a way to figure out what OS the compiler/runtime we are calling is designed to run under, in order to use to_native properly. EG: under Cygwin, if we call the Cygwin DMD, it will make a .SO file. But if there is no Cygwin DMD installed, it will look into Windows and call the Windows DMD, and make a .DLL file.

So instead of it being dependent on the OS we are running under. It is dependent on the program we are calling.