[tracking] Better error handling

This is a general tracking issue for the removal of (or to at least greatly
diminish the presence of) unwraps and expects, to guard against runtime
panics.

Some tasks that come to mind:

• Convert all Result<..., String> types to be Result<..., Error> and roll an
  Error enum for each place with a non-trivial amount of errors to handle
  • As a result (no pun intended), convert instances of unwrap/expect,
    wherever possible, to use the ? operator to propagate errors up
  • Maybe use anyhow to reduce boilerplate?
• Remove as many instances of unwrap and expect as possible in order to
  decrease the occurrence of panics
  • At the very least, convert unwraps to expects, to indicate what the problem was and where it occurred

cc @grahamc

Start by inventorying the project's unwrap, expect, and Result<..., String> uses to identify a focused area with non-trivial error handling. Check whether existing error enums or propagation patterns provide a suitable scope. Done means reducing panics in the selected area and using informative, typed error handling where appropriate.