"try" semantics

[warpfork]

Hello! Spacemonkey errors are awesome! Using them in my projects has resulted in a huge reduction in boilerplate and grouping things into hierarchies has made my errors and handling much cleaner!

This is a package that attempts to take boilerplate reduction a step further, and replace frequent three-liner if err := whatever(); err != nil { return err } error handling blocks and replace them with... well, zero liners, by using panics instead. To make this feel cozy, this try package makes semantics that feel like try/catch semantics in other languages, and makes it easy to use spacemonkey error type hierarchies to trigger different handling paths. The example test functions in the PR should be pretty good demonstrations of how the syntax works.

Panics aren't for everybody (or every situation), I know. This would represent a totally optional way to use spacemonkey errors, and so is isolated off in a sub-package. If a project is happy on the path of error returns, they'll have no reason to ever import the try package. And indeed, return-style errors are still often a good idea in many situations ('specially around concurrent work, where they're effectively required for channel/cross-goroutine reporting, even if the majority of the program is using panics and try within individual goroutines) -- so there's some package docs that attempt to highlight that, and it's purposefully easy to use the CatchAll system to flip panics back into return-style errors. Another school of thought has panics as being valid within packages, but impolite to expose across package boundaries (stdlib encoding libraries are known for doing this internally), and try should be totally easy to use like that, too.

I've been incubating this in usage in some projects for a while now (as you can see from the commit timestamps...) and it's been working pretty well, so I thought I'd share and see if anyone thinks this is an interesting enough pattern to upstream :D

[warpfork]

This is a super terrible test. I could say I left it in so it could spark some discussion, but really, I just forgot it was here.

I'd love suggestions for how to get coverage or describe this behavior correctly... otherwise it should probably thrown away, because all it does is print stuff that has to be eyeballed, and that's just not a test.