refactor exception handling to close #23

[jumblerg]

@micha please review -- there might be additional cases i failed to take into account in this fix. i don't recall what the originally-intended purpose of the ex fns was, but they seem unnecessary now. currently left for compatibility reasons, but should we remove them entirely - are they considered part of the public api?

https://github.com/jumblerg/castra/blob/master/src/castra/core.clj#L16-L18

similarly, should we also dissoc status, message, stack and case from ex? also preserved for backwards compatibility in this commit.

https://github.com/jumblerg/castra/blob/master/src/castra/core.cljs#L42

[jumblerg]

i also find it quite annoying that, during development, certain classes of errors are propagated up to the client while others appear in the server console; could/should errors being handled by castra still be logged to the console in some fashion?