Sweeping removal of .unwrap() and .expect() in library code

[ounsworth]

Nikola requests that we do a sweeping change focusing on removal of excessive use of .unwrap() or .execpt() in order to reduce the surface for the library to abort on error.

So the task for this ticket is to systematically go through all the .unwrap() and .expect() sites within the library and see if any can be removed -- not forwarded to the caller, which is just as bad, but removed by restructuring the code so that the error is structurally eliminated.

[ounsworth]

I personally feel that I have been very careful in applying the following philosophy -- in ranked order:

1. The library should return errors to the caller only in instances of bad input (either bad input data or bad state).
2. The library should never forward errors to the caller due to bad programming within the library (for example, internally using a hash in an invalid state, or triggering a hazardous KeyMaterial error outside of a do_haz_ops block). In these cases, the correct behaviour is to use a .unwrap() or .expect() inside the library, document via a comment why this is expected to be infallible, and provide good unit testing to convince ourselves that this is un-triggerable.

So if I have done my job well, I hope there are already very few call sites of .unwrap() or .expect() that can be removed, but I bet there are some.