CloudinaryException is too vague

We've seen messages like `Resource not found` and `Error in loading`, which we'd like to handle as generic HTTP client errors (400-499). Unfortunately, we have to rescue the `CloudinaryException`, check its error message, and then determine what should be done.

I would propose having more than one exception class to make it possible for us to rescue something like `Cloudinary::HttpClientError` to ignore errors like HTTP 403 (Forbidden), 404 (Not Found), 408 (Request Timeout), etc.

One way to do this would be to add `class Cloudinary::HttpClientError < CloudinaryException; end` and then use that error for the cases that represent HTTP 400-499.

Locate CloudinaryException and the HTTP response handling that currently produces messages such as "Resource not found" and "Error in loading." Trace how 400–499 responses are classified, then define the exception hierarchy and verify that the relevant client errors can be rescued separately. The issue does not mention specific files or tests, so the existing exception and HTTP-client test coverage should be identified first.

Scritto dal modello di indicizzazione a partire dal testo della issue.