more error type polishing needed

While working on #102 I realized there are some larger considerations to make around error types. I feel like consolidating the various admin API error types into OpteError turned out quite well. However, with the processing error types I'm not sure if they should all be flattened to fit into OpteError as well (which may explode the enum quite a bit and lose some fidelity with the process() error return) or if these types should be partially merged but also have some of their own variants in OpteError which nest somewhat. Or maybe there should be a top-level ProcessError and have that nest into OpteError, etc. The point being that I need to sit down and figure out what provides the most value in the context of debugging problems in production.

That said, this issue should be near the top of the list and dealt with in the next week or so.

Hint for future Ryan: Start with all the TODO kill unwrap lines.

Start by locating every TODO kill unwrap line and tracing the processing error types returned by process(). Review how the admin API errors were consolidated into OpteError, then document the desired error hierarchy and its production-debugging tradeoffs. Done means the error design is decided and consistently applied.