Add a mechanism to set the max stack size

[brson]

Right now we can recurse until memory runs out. There should probably be a way to control the maximum stack size, with some default value

[thoughtpolice]

In the case of GHC, all executables can accept certain flags at runtime which are passed onto the runtime system controlling various options like this. For example, if foo.hs is compiled to foo.exe, then you can invoke foo.exe and specify a maximum stack size like:

$ ./foo.exe arg1 arg2 arg3 +RTS -K512k -RTS

Anything inbetween the magical +RTS and -RTS flags are interpreted by the runtime system (and if there is no -RTS flag, then all the remaining flags following +RTS are interpreted as flags for the runtime.) This can also control things like the amount of OS threads to spread lightweight threads across, etc.

While this does steal the +RTS and -RTS arguments away from every compiled executable, in practice it doesn't seem to be too much of a problem I think. This is an easy way to let every compiled executable have its own settings at runtime, with a reasonable default should nothing be specified

A sidenote: recent GHC currently doesn't quite let you do this, because there's a security concern where you could execute a program and DoS the machine by specifying an abundant amount of threads, huge amount of memory, etc. So by default it's rather conservative in some of the things it allows you to pass to the +RTS.

At the same time, GHC lets you handle the situation of no -rtsopts but needing special RTS options a few ways, check out the docs here: http://www.haskell.org/ghc/docs/7.2.2/html/users_guide/runtime-control.html

Perhaps the -rtsopts flag is a bit overkill here, but I think the general idea works pretty well in practice.

[brson]

We're using a somewhat disorganized set of environment variables for that purpose at the moment. It would be pretty simple to teach rust_start to extract them from the command line as well.

[brson]

Opened #1497 for -RTS +RTS