Returning an error code whose zero value indicates success is
a reasonable pattern, in C.

We are not programming in C.

Eventually we're going to get rid of this pattern entirely. For now,
we can at least use a real `Option` type to indicate whether an error
in fact exists.

Also, the Proteus implementation specifies that the error code is
a `u16`. No idea why that got widened to a `u32`, but that was
pointless, so it's back to a `u16` here.

Clients only care about a limited set of errors, which we enumerated
in the root issue. This commit refactors the client-visible errors
(in WASM) to focus only on the set they care about.

Clients only care about a limited set of errors, which we enumerated
in the root issue. This commit refactors the client-visible errors
(other than WASM) to focus only on the set they care about.

Turns out there is a whole human-written section in the TS bindings which parses the
output of our error types and turns it into a somewhat better error object.
That needed to be updated to handle the new, simpler output serialization.

Kotlin tests are still failing due to previous changes, but at least
the fundamental build operation is now succeeding. It's a start!

Ran a Kotlin code formatter, intending only to hit the auto-generated files;
turns out there were a bunch of human-maintained files in the tree also.
Unfortunately, at that point, there were quite a lot of uncommitted changes.
Didn't want to go through the effort of going back and unformatting the
unrelated stuff, so that's all in here also.