Provide way for publishing errors and allowing clients to deserialize them

[dansanduleac]

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

[chris05atm]

This would be useful for an internal product codenamed SW and for a customer account.