Add rure, a C API.

[BurntSushi]

This commit contains a new sub-crate called regex-capi which provides
a C library called rure.

A new RegexBuilder type was also added to the Rust API proper, which
permits both users of C and Rust to tweak various knobs on a Regex.
This fixes issue #166.

Since it's likely that this API will be used to provide bindings to
other languages, I've created bindings to Go as a proof of concept:
https://github.com/BurntSushi/rure-go --- to my knowledge, the wrapper
has as little overhead as it can. It was in particular important for the
C library to not store any pointers provided by the caller, as this can
be problematic in languages with managed runtimes and a moving GC.

The C API doesn't expose RegexSet and a few other convenience functions
such as splitting or replacing. That can be future work.

Note that the regex-capi crate requires Rust 1.9, since it uses
panic::catch_unwind.

This also includes tests of basic API functionality and a commented
example. Both should now run as part of CI.

[BurntSushi]

@alexcrichton Some thoughts:

1. I'm not much of a C programmer, so don't assume I know what I'm doing. :-)
2. Does my use of panic::catch_unwind look right/reasonable?
3. How about the structure of regex-capi and naming? I mostly got this structure from tendril and it seems reasonable.

[huonw]

This could theoretically incorporate more of the FFI set-up, e.g.

macro_rules! ffi_fn {
     (fn $name: ident($($arg: ident: $arg_ty: ty),*) -> $ret: ty $body: block) => {
          #[no_mangle]
          pub extern fn $name($($arg: $arg_ty),*) -> $ret { ... }
     }
}

ffi_fn! {
    fn rust_compile_must(pattern: *const c_char) -> *const Regex { ... }
}

[BurntSushi]

Nice, thank you. I did this. It'd be cool to just have one ffi block and stuff all the extern fns in it, but I think that makes the macro much more complex.