Improve Error Handling

[ethanndickson]

Currently, library interfaces expose the anyhow Error type, a universal, opaque error type that includes error context as a string.

Since we are unable to envisage exactly how users of the library might want to handle errors, it would be more appropriate to build transparent error types that provide more insight into why operations failed, and expose those instead.

With this implemented it may then be sensible to have user defined callbacks accept a Result<T> instead of a T as their argument, to allow users to specify their own error handling behaviour - though this would be a breaking API change.