Improve error handling

[JohannesHome]

Hey, with the api v3 changes the error handling seems to have changed somehow, we are seeing lots of FigoExceptions now.

Sadly, this exception isn't helpful in some cases where the underlying ErrorObject of the api returns meaningful information that is not propagated.

Problems:

FigoException

• missing exception message
  • often there is only a description and no message, which means the Exception.message is null (maybe have a fall back to the description?)
• missing error code
  • handling is difficult as the error_code is often part of the message (404 = 1002 etc)
• missing data
  • in case of schema errors there is no way to tell what is wrong based on the description

Most of these problems could be solved simply by returning the ErrorObject, and adding data to it.

[JohannesHome]

Hmm, I'm just realising that the 1.5.9 changed stuff that broke our error handling.

For example, the library now logs every api resonse as an error, even though we have implemented handling on higher instances. So we are now seeing error logs, that are not errors in our case. Examples are 404, and 401 that occur do to stale data, which is handled by our application code and is not considered an error.

Furthermore, our higher instances are broken as they relied on the error messages to be a certain way. (e.g. access_denied and Entry not found.).

[JohannesHome]

I created a PR that simply adds a specific exception type that wraps the api error response, which should help me handle most of the issues I'm having: #52