add support for Maybe APIs.

[cowboyd]

This adds some conversion classes to automatically unbox both Maybe<T>, and MaybeLocal<T> values, which lays the basis for https://github.com/cowboyd/therubyracer/pull/354 (originally https://github.com/stormbreakerbg/therubyracer/pull/5)

In general, you take the conversion class, and access the ::Maybe class underneath it. For example, to unbox values of v8::Maybe<v8::String>, you'd use String::Maybe()

This PR doesn't add all the helpers, but some and an example in the implementation of the v8::String.ToString() method.

I've tried to get a failing test in spec/c/maybe_spec but can't seem to do it.

[cowboyd]

Oops, looks like I branched this off of https://github.com/cowboyd/therubyracer/pull/353, so should review and merge that one first.

[cowboyd]

You know, it occurred to me: maybe this is something that should be left up to the next layer. It's just as easy to throw an exception in Ruby as it is for C, in fact, it's easier if that's what we want to do in every case. Clearly, the V8 developers conceived this mechanism as a way to defer error handling to the embedder, so why not pass that responsibility on above the C layer.

We could implement it like so:

+`V8::C::Maybe`
|
+- V8::C::Just
|
+- V8::C::Nothing

And then have our maybe helper either return an instance of Nothing or Just depending on what gets returned. This hues closer to the ideal of the C layer which is to be as faithful a representation of the low-level V8 api as possible.

[georgyangelov]

I agree. The fewer things we have in the C++ code, the better.

[cowboyd]

superceded by #364