Adds ability to capture HTTP errors

[codenamev]

As of v4.0.0 of this gem, we lost the ability to access response headers and response status code. Access to these is critical in safely handling HTTP failures that can happen when reaching out to OpenAI's API.

This introduces a new configuration option raise_error that allows users to raise a new OpenAI::HTTP::Error anytime the response status code is 4xx or 5xx, and provides access to the response's status, headers, and body on the error instance that is raised.

In #327, an approach to resolve this allows forcing a "raw" response to be returned. For the specific case of handling HTTP errors though, this is not a straightforward solution that I would expect as a first-time user of the library.

Since Faraday is used, they have an excellent RaiseError middleware (recommended in their docs) that will raise a Faraday::Error for any 4xx or 5xx response status codes. Instances of this error contain a response Hash attribute that include the status, headers, and body of the response. This takes advantage of that error class and wraps it in a library-specific one so that end-users can rescue from this in a convenient way.

Some dis-advantages to this solution is that it is coupled with Faraday. However, extending the new OpenAI::HTTP::Error class to conform to the same return object for the response accessor (a Hash with status, headers, and body keys) should be fairly straightforward if it is decided to move away from Farday in the future. I have tried my best to avoid any Farday-specific mentions in the README for that reason.

Fixes #255

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you added an explanation of what your changes do and why you'd like us to include them?

[codenamev]

@alexrudall I left the rubocop failures since resolving them will require some re-organization of the HTTP module (due to it's line-length). If this idea is acceptable, I can circle back and adjust; but I'd love to just bump that number in the rubocop config since it's only off by a few lines.

[atesgoral]

@codenamev In #342 I'm taking a more opinionated approach of not making error throwing optional. Also found a way throw the Faraday exceptions while streaming.

[alexrudall]

Really appreciate this contribution @codenamev - going with #344 as it's a little simpler and includes error details by default. BUT contributions like this help explore alternatives so it's seriously appreciated. 🙏