Remove catching of exceptions inside field resolver functions

[hlship]

Fixes #82 -- in the current form, the exception capturing is very aggressive, gets in the way of debugging when things go wrong.

[candid82]

Would it be simpler to not catch exceptions at all and let users handle them however they want?

[hlship]

Given the mea culpa on decorators, that's worth considering. But still, this feels like something that will be applied uniformly across resolvers.

The existing code catches the exception, converts to an error map, and adds to the error map a number of keys to identify the source in the query document of the failure.

Perhaps we could see about stripping that out, so that an exception simply bubbles up, and probably gets caught back inside the Pedestal interceptor chain.

[candid82]

The only potential problem I see here is async resolvers. Not sure how exceptions will propagate in async world.

[hlship]

The docs on async are already very specific about exceptions: catch them or your system will grind to a halt.

[hlship]

Side note: the need to capture field resolver exceptions dates back to much earlier Lacinia, before the introduction of ResolverResult. With this change, the main execution flow has no try/catch at all (there's some in parsing and validation).