reify failures in the controller

[zliu41]

This is work that can be done incrementally, so perhaps this should be an epic, but for now, a list.

1. replace any uses of error with structured types and impureThrow (see https://gerrit.heavisoft.kittyhawk.aero/c/heavisoft/+/13613 for first steps here)

The structured types will need a manual Show instance that builds the previous error message, so the resulting output is the same. And they'll need an empty Exception instance so they can be thrown.

This is the first step that has a few benefits

we get away from strings (concatenation of which does not play well with the controller frontend)

we have structured failures that constrain what can go wrongbut it also has some shortcomings relative to the goal

serialization is still defined alongside the data type, rather than closer to the user

the types still don't indicate failure

2. push the calls to impureThrow down the call stack as far as possible, using Either (or Validation) to get them to that point. This should also replace impureThrow with throwIO when possible.

3. replace calls to impureThrow with throwAsException (and throwIO with throwIOAsException), eliminating the manual Show and Exception instances that were created in step 1, moving the show definitions into standalone a -> String functions near the throw site.

This last step might require other changes to the frontend, because AsException may be hard to HasRep, which is why this is separate from the other steps. We can address this separately and maybe simplify the steps here.

(Extricated from https://kitty-hawk.atlassian.net/browse/SW-2658)

[peddie]

Duplicate of #24 ?