Handle invalid/empty JSON response

WordPress.org REST API returns an invalid JSON if the resulting response won't contain any data. For example, [`/wp/v2/users/)/application-passwords`](https://developer.wordpress.org/rest-api/reference/application-passwords/) endpoint only returns the `password` field while creating a new application token. So, if we make a request and only ask for `password` field for a `GET` request, it would return an empty response. The problem is, it returns `[[]]` instead of `[{}]` changing the JSON format.

```
curl --user test@example.com:{token} "http://localhost/wp-json/wp/v2/users/1/application-passwords?context=edit&_fields=password"
```

We tried to address this problem in #172 by trying to eliminate invalid requests. However, this request ^ is a valid one as far as we are concerned - unless we want to specifically disallow it as a special case - so, our work in #172 does not address this case. (rightly so)

This request currently results in `WpApiError::ParsingError` which is a decent and hands off way to handle the issue. However, this behaviour seems to be common across all endpoints, so it might be worth to convert this to return either a successful empty response or a specific error.

I am not sold on any solution yet - and maybe what we have right now is the best one after all - so, my main goal with this issue is to document the behavior.

Note that, as I was documenting the issue, I was initially against converting it to a successful response. I thought the response we get back was always `[[]]` regardless of the number of items, however I've tested this by adding a new application token and observed that the response changed to `[[],[]]`. So, it _looks like_ the only problem is the conversion from JSON object to JSON array. As long as we are careful with preserving the number of items, I think converting it to a successful response should be fine - although I'd still question its merit. Mainly because when we make a request with `_fields=`, meaning asking for no fields and treating the request as if we are trying to do a `COUNT` request, the server responds with all fields. So, I think it'd be kind of against the current API design to do this 🤷

---

**Reminder**

In our integration tests, this special case is handled by skipping `application-passwords` tests that would only request the `password` field as can be seen in #181. We need to update that implementation as part of this issue.