Improve error-handler to accommodate for ErrorDetails and non-JSON/HTML responses

[hmmwhatsthisdo]

Description

This PR modifies Invoke-JiraMethod to improve error-parsing under certain conditions.

More specifically, the following changes have been made:

• Appropriately parse errors in the event the Jira API returns an error in a manner that populates the ErrorDetails field on the associated exception. (see #276)
• Handle API responses that are neither valid JSON nor HTML.
• Catch errors that only include the errorMessages property versus the errors property.

Motivation and Context

If Jira (or the web server/proxy used to access it) is using Chunked transfer encoding, for instance, this field may not be populated (see this PowerShell UserVoice post).

This PR resolves #276.

Types of changes

• [X] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [X] My code follows the code style of this project.
• [ ] I have added Pester Tests that describe what my changes should do.
• [X] I have updated the documentation accordingly.

[hmmwhatsthisdo]

One of the things that may need additional refinement (probably in a separate PR) is how to handle non-JSON/HTML error responses.

For instance, this behemoth is spat out of the API if invalid credentials are passed to New-JiraSession. It seems to be a mixture of JavaScript and plain-text, which isn't a particularly easy thing to parse without resorting to regexes or something more hamfisted. Apparently this is/was due to Test-ServerResponse not being called appropriately following edge-case exception behavior during login.

[hmmwhatsthisdo]

@lipkau The New-JiraVersion integration tests appear to be 400ing - FWICT this can be caused by trying to create an issue where one with the same name already exists. Can you verify whether this is the case on the integration-test instance?