Provide way for publishing errors and allowing clients to deserialize them

What happened?

Currently, it's a pain for a service high-level-foo to propagate RemoteExceptions coming from another service low-level-foo to its own clients (they have to deserialize the RemoteException, then turn it into a ServiceException and throw that, otherwise RemoteExceptions always map to 500).

A big challenge here lies in having to manually pick out the right arguments by name from the RemoteException, with no error occurring if mistakes were made.

What did you want to happen?

Would be good for services that throw conjure exceptions to

1. publish the arguments of those exceptions as a (conjure) object that has a clear structure
2. provide a way to parse a RemoteException into a given error defined in the API that you consume

Then, the high-level-foo service maintainer can just attempt to convert the RemoteException into one or more "expected" exceptions, and handle each one in a type safe way.

This probably requires conjure-backcompat to enforce backcompat on the arguments defined for each error code, such that renaming an error would be an API break, and so would removing / renaming previously declared arguments of that error.

cc @JiahuiJiang

Start by tracing RemoteException handling and the generated conjure exception representations described in the issue. Determine how exception arguments are currently exposed and converted across service boundaries, then define the API and compatibility checks needed for typed deserialization. Done means clients can publish structured exception arguments and safely parse expected errors without manual argument lookup.