Improved error handling for variables parsing

[OlegIlyenko]

As discussed in #168, this PR improves error reporting for variable parsing:

Here I handle 3 general cases:

• variables are null/undefined or an empty string - variables set to null
• variables string contains malformed JSON - result pane will show a detailed error message
• variables JSON is valid, but does not contain a JSON object - result pane will show an error message: "Variables are not a JSON object."

Along the way I also noticed that "Fetcher did not return Promise or Observable." error was not reported correctly. Existing code was setting the state, but after _fetchQuery is finished, the state is immediately reset once again. It works for all other scenarios because they all set the state in an async callbacks, but it's not that case with "Fetcher did not return Promise or Observable." error. In order to solve the issue, I refactored this bit with throw/try/catch.

[asiandrummer]

Instead of showing a string, should we create a JSON error format for these errors, like the ones that server gives back?

{
  "errors": [
    {
      "message": "Variables are invalid JSON."
    }
  ]
}

[OlegIlyenko]

I think I would prefer to keep it as a simple string for these 2 reasons:

• As far as I can tell, other parts of GraphiQL also follow this pattern and render errors as a string ("Fetcher did not return Promise or Observable." is an example of it). But maybe I missed something?
• Rendering this error as a JSON may case a confusion because it looks exactly like a server response, even though no request was sent to the server in case of malformed variables.

WDYT?

[asiandrummer]

I can agree with that ;p

[asiandrummer]

@OlegIlyenko thanks for taking care of this ;)