Fix mutation promise result type and provide utility to work with the result

[svsool]

Hi, thanks for this library.

I think that mutation promise is wrongly typed and it should be typed as Js.Promise.t(executionResult)

That means I can't use convertJsInputToReason to parse data in Js.Promise.then_ as for instance it's done here https://github.com/tmepple/my-react-app/blob/d47b0b0f2de3d44b1b8dd06f0db2194c0ef987c3/src/components/SignupForm.re#L122 because it's not safe

This PR is intended to fix aforementioned problems

[apollo-cla]

@svsool: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[fakenickels]

Good one!

[baransu]

What's required to merge and ship it?

[Gregoirevda]

I reverted
shouldn't the transformation from JS Object to Variant be done when the mutation is called?
https://github.com/apollographql/reason-apollo/pull/132/files#diff-58f21bf0169e41485aa3fd2553abd3e5R41

[svsool]

My initial idea was to use convertExecutionResultToReason manually to map executionResult (JS Object) to executionResponse variant, same way as it's done here but with correct type, also that way it will be backward compatible and won't break code that already expect JS Object as mutation promise result (there is probably no such code, because type was wrong). But in general I think variant can be passed instead of plain object when mutation is called, if you mean Js.Promise.t(executionResponse('a)) instead of Js.Promise.t(executionResult).

[tmepple]

Even though it's a breaking change for the referenced code I definitely think we should be getting back the Variant when the mutation is called rather than having to always call the transformation function manually.

[Gregoirevda]

Think so too, I'll add it this week end if I have time

[Gregoirevda]

Fixed in #164 and merged