Define a hierarchy of error classes

[chanks]

Defines a hierarchy of error classes for the SDK. All errors descend from Square::Errors::ApiError, and it currently has two direct descendants:

• Square::Errors::TimeoutError, which represents request timeouts to the server.
• Square::Errors::ApiError, which (with its subclasses) represents unexpected API responses. There are status-code specific subclasses to reflect the error cases which we expect to be most commonly need handling, but these are of course extensible in the future.

The subclass approach lets SDK users handle errors as granularly as they like:

client = Square::Client.new(base_url: "url_goes_here")

begin
  list = client.cards.list
rescue Square::Errors::TimeoutError
  puts "Square API didn't respond before our timeout elapsed"
rescue Square::Errors::ServiceUnavailableError
  puts "Square API returned status 503, is probably overloaded, try again later"
rescue Square::Errors::ServerError
  puts "Square API returned some other 5xx status, this is probably a bug"
rescue Square::Errors::ResponseError => e
  puts "Square API returned an unexpected status other than 5xx: #{e.code} {e.message}"
rescue Square::Errors::ApiError => e
  puts "Some other error occurred when calling the Square API: {e.message}"
end

Other notes:

• The Net::HTTPRequestTimeout -> Square::Errors::TimeoutError conversion might seem pointless, but I'd like to maintain the ability to swap out Net::HTTP for a different networking layer in the future if we want to, and in that case it'll be an easier transition for SDK users if they're handling Square::Errors::TimeoutError rather than Net::HTTPRequestTimeout directly.
• Along those lines, I considered also wrapping JSON parsing errors in our own error type, but my feeling is that an error in JSON parsing is indicative of a design error in either this SDK or code that calls it, and I don't want to encourage rescuing from JSON parsing errors as a matter of course. If a user of this SDK needs to work around a JSON parsing issue temporarily they can easily rescue from JSON::ParserError if they need to.
• I've opted to define a Square::Errors module to group our error classes in - we could leave them at the top level (Square::TimeoutError, etc) but I think that that pollutes the Square module namespace, which is already being populated by many autogenerated classes. I think Errors makes sense as a grouping of user-exposed classes (similar to the way we currently use Square::Types) but I'm happy to be persuaded otherwise.
• While a Square-defined error type already exists (Square::Types::Error), providing the tooling to parse and utilize its information in the SDK's error classes is complicated and outside the scope of this PR.