Format error messages consistently

The error messages are now presented in this format:

    JIRA::REST Error[<CODE> - <TEXT>]:
    <CONTENT>

<CODE> is the HTTP response code. If the error isn't related to a REST
HTTP invokation, then we use 500.

<TEXT> is the textual representation of <CODE>, which we get using the
HTTP::Status::status_message routine.

<CONTENT> is whatever content comes with the HTTP response. JIRA errors
usually come in a JSON structure that we parse to present only the
textual message. Other Content-Types are parsed as well: text/plain and
text/html (with HTML::TreeBuilder). Otherwise, the user gets a message
telling him which unsupported Content-Type we got from the HTTP
response.
Add search iterator methods

The utility methods set_search_iterator and next_issue utility methods
allow you to iterate through large sets of issues without worrying about
the startAt/total/offset attributes in the response from the /search
REST endpoint. These methods implement the "paging" algorithm needed to
work with those attributes.
Simplify the SYNOPSIS documentation section
v0.005

  [Changes]

  - New utility methods 'set_search_iterator' and 'next_issue' make it
    easier to iterate through large sets of issues without having to deal
    with "pagination".

  - Error messages are not presented in a consistent format. JIRA errors are
    parsed and presented in a legible way.
Placate Perl::Critic
Suppress script line number from error messages

The _error function was returning a message with trailing newlines
stripped off so that when the message was croaked Perl appended a script
name and line number to it.

Now _error returns messages with a single trailing newline to make Perl
be less verbose.