middleware still returns a string, when JSON is expected

[xcambar]

This issue is a follow up on #251 , which apparently doesn't fix the handler's behavior in some situations.

I am currently still facing the behavior described in #251 using [email protected].

Here's the received response as breakpoint'd at https://github.com/kategengler/ember-cli-code-coverage/blob/master/lib/templates/test-body-footer.html#L22 (with some entries removed for readability)

{
  "readyState": 4,
  "requestHeaders": {
    "Content-Type": "application/json; charset=utf-8"
  },
  "status": 200,
  "statusText": "OK",
  "method": "POST",
  "url": "/write-coverage",
  "async": true,
  "responseText": "{\"lines\":{\"total\":493,\"covered\":432,\"skipped\":0,\"pct\":87.63},\"statements\":{\"total\":500,\"covered\":437,\"skipped\":0,\"pct\":87.4},\"functions\":{\"total\":167,\"covered\":138,\"skipped\":0,\"pct\":82.63},\"branches\":{\"total\":283,\"covered\":244,\"skipped\":0,\"pct\":86.22}}",
  "response": "{\"lines\":{\"total\":493,\"covered\":432,\"skipped\":0,\"pct\":87.63},\"statements\":{\"total\":500,\"covered\":437,\"skipped\":0,\"pct\":87.4},\"functions\":{\"total\":167,\"covered\":138,\"skipped\":0,\"pct\":82.63},\"branches\":{\"total\":283,\"covered\":244,\"skipped\":0,\"pct\":86.22}}",
  "responseXML": null,
  "responseURL": "http://localhost:7357/write-coverage",
  "sendFlag": true,
  "responseType": "json",
  "errorFlag": false
}

As you can see, the responseType is json, yet the response and responseText are both Strings (both valid in their own rights).

---

I am a bit at a loss regarding the fix.

This does not really look like a bug from the handler to me, since a string is strictly speaking valid JSON. Which makes me tempted to bring this to istanbul-lib-coverage.

On the other hand, a stupidly easy fix would be to restore some of the removed logic in this PR, specifically https://github.com/kategengler/ember-cli-code-coverage/pull/251/files#diff-94eab975fb48e219fc130d82e21457acL57-L58

I will validate the second option locally and if the results are satisfying on our fleet of repos using ember-cli-code-coverage, I will propose it here. Meanwhile, I'm looking forward to your input and opinion on the best portion of the code to try and apply a fix.

[ndekeister-us]

I can confirm that using 1.0.0-beta.9 works as expected

(we spotted this issue when using COVERAGE=true yarn ember try:one ember-default in our addon, which was installing version 1.0.0 instead of version 1.0.0-beta.9 defined in our yarn.lock)