Allow config/2 to send errors in spec compliant format

[bryanjos]

Related to #1340

This PR makes it so that if config/2 returns an error tuple where the second element is a map, then that map is treated as the error response.

Subscription config errors currently expect a tuple of {:error, msg }. If message is an map, when returned to the user, it looks like:

"errors": [
    {"message": {"extensions": {"code": "BAD_REQUEST"}, "message": "Invalid argument"}}
]

This causes trouble for us as we return spec compliant errors and they get wrapped in the message.

This PR makes it so returning the following from config/2

{:error, %{message: "Invalid argument", extensions: %{code: "BAD_REQUEST"}}

Will return

"errors": [
    {"extensions": {"code": "BAD_REQUEST"}, "message": "Invalid argument"}
]

[michaelcaterisano]

Seems reasonable to me!

[benwilson512]

I'm perfectly happy to let ya'll decide and move forward on this. I would recommend adding a test case after this to absinthe_phoenix to make sure this actually works end to end.

[bryanjos]

I wrote a test case for absinthe_phoenix locally and verified everything passes. I can make a PR there