Parse more error formats from Quasar

[kritzcreek]

Also extracts a title and a message field for errors which contain more details.

I tried to produce quasar errors in slamdata and found the formats I'm parsing in this PR. I found that some of them contain both a title as well as a more detailed message, so I added a new QError constructor which captures this.

When we get to redesigning the error card having both of these should allow for a nicer UI with a title and details. This will cause all kinds of type errors in slamdata so I thought I'd show what I have and get some critique before continuing.

[jdegoes]

@kRITZCREEK It may also be a good idea to document these formats for the backend team. Ideally, Quasar would be utilizing a unified format for reporting of all error messages.

[kritzcreek]

@jdegoes Yes ideally we'd have one big ADT for all the errors Quasar could throw, and wrap that in a constructor that contains the best human-readable error message Quasar could come up with.

If we then decide we have enough semantic context in the frontend to improve on the error message Quasar can give, then we can discard the String error and use the structured format.

How viable this is depends a lot on how fast Quasar is changing, which I can't judge at the moment. Something like Servant's API as a type would be optimal here 😈

[wemrysi]

All Quasar errors should serialize to JSON like {"error": {"status": <short description>, "detail": { ... }}} where the detail field is currently optional. A common detail field is message which will contain a more detailed description than status. detail may also include other fields, depending on the particular error.

If this isn't enough structure, or a you think a different format would be more helpful, suggestions are welcome!