Error handing in the framework

Think what we want to do with Exceptions, I'm on the fence but probably we should not enforce anything to the user's HTTP layer.

To quote myself:

I would not want to enforce a global error handler in the framework in case someone would want to deal with other GraphQL services in the app, but this brings an important topic, should those errors be HTTPErrors or should those be "framework" errors? What I'm getting at is that the framework should not enforce the error schema of an app but rather expose the ability to handle (documented) errors in the way a user of the framework wants, i.e. on SaleorAuthenticationError one would like to respond with a 403:

{
    "error": "Authentication with Saleor bad"
}

while another may want to do something like application/problem+json https://datatracker.ietf.org/doc/html/rfc7807

The issue names no files, tests, or entry points. Start by reviewing the proposed handling of Exceptions, SaleorAuthenticationError, and the linked RFC 7807, then determine whether the framework should expose documented errors without enforcing an HTTP schema. Done means the error-handling contract and supported response customization are decided and documented.