Sdk, module and running configuration

Ok, this is a exciting and a rather large one :smiley: Everything has only been tested in OSX. It *might* work on Linux, and it will almost certainly *not* work on Windows (i.e. I haven't added the `.exe` extension in all the places we need. This should be easy to fix, anyway)

* You can now create a Rust SDK. To do so, specify the place where `rustc` lives. After that, `rustc --version` will be run, and after getting the host triple, I check on `../lib/<triple>/librust` for libraries, although I don't do anything with them yet.
* You can create a Rust module as well. There is no `right click -> New -> Rust` yet, but that's easy to add (I'll add it later). For now, use `New -> File` and use a `.rs` extension, although you probably know that already :smile:
* You can also create a run configuration (not a debug one for now). You *must* specify the "Main file" argument, and it will have to be something like "src/main.rs", i.e. the relative path to your main file from your module. The path will be colored red as if there were errors, I know. Also, clicking on the `...` button doesn't work yet.
* There is no way of compiling without running (Cmd+F9). If you try it, it will throw an error.
* When you try to run, a compilation will first start, and any errors (and probably warnings, although I haven't tested them yet) will show on your file. You can double click to go to the error, exactly like in Java. I love this part, and spent a lot of time to make it work :smiley: 

The code for compiling and running is a mess, unfortunately, as I copied large amounts of it from the Java  target (and some non-compiling parts from Go, they have an awesome IDEA plugin already). The problem is, some of it is from 2003, when the APIs were different/non-existent. Also, Java is very intertwined with a lot of things in IDEA. That means, I'm probably not using the best API to do all the compilation, and half of the code I added for it is not used, but is the best I can do for now.

This will probably need lots of QA and QR, so let me know of any problem you find.
Yeah, it might be a better option, although I try to avoid them because they're slower and will create garbage, although in this case we're not expecting a lot of output, so it might be better and will be easier to read as you said.

However, this is still a bit of a hack. I don't like having to parse `rustc` output. The best solution will be driving the compiler directly, but I don't know how feasible it is to do that, although I assume JNI will have no problem with it.

That's the approach I'm taking with debugging, working on that now, driving LLDB through `liblldb` with bindings I created with SWIG.