Support for using the GNUstep blocks runtime

[ngrewe]

Hi!

Another pull request for better support for non-Apple OSes. This adds support for linking against the GNUstep blocks runtime.

[ngrewe]

Hey SSheldon!

I've been dusting off a PoC I did a while ago and found a few things that needed a bit of fixup, including the blocks interface. In fact, I had all but forgotten that I already had opened a PR for this, but it seems that it has been a bit obsoleted by the inclusion of libBlocksRuntime support on Linux. Unfortunately, that's not quite sufficient for my use case, for the following reason:

On Linux, the libBlocksRuntime from compiler-rt is perfectly fine for use in a pure C setting, but it is incompatible with the GNUstep Objective-C ABI, so it can't be used to interoperate with Objective-C code (in particular, copying/releasing blocks might just crash, or worse, silently corrupt state), so Objective-C code needs to use the _Blocks* functions provided by the GNUstep Objective-C runtime. This means that you have three different libraries you might want to link the crate against: System.framework on OS X/iOS, and libBlocksRuntime or libobjc on non-Apple platforms.

To tackle that I've done some autoconf-ish stuff in the build script: On Apple platforms, it unconditionally (and without build dependency on the gcc crate) emits a linker instruction for rustc to link System.framework. On all other platforms, it will try to link a small program that references the _Block_copy symbol against libBlocksRuntime and libobjc. I've also updated the travis-ci job to build against both runtimes.

Please let me know what you think!

Thanks,

Niels