Make errors handleable

[junha1]

Most of errors that caused by unexpected behavior of the other side's RTO port will just lead to panic.
However, especially in Foundry context, the other port might have been implemented by 3rd party and could be unreliable.
In this kind of cases, user will just want to handle the error, not panic.

One trivial solution is adding a Failed state for the RTO context. The context will be on Failed state when it encounters unexpected protocol error, and will be stopped. Users can notice this, and can handle with theirs means.

One drawback of supporting such error handling is the interface of service object; it might be mandatory to all methods to have Result<> as return types.

Depends on #76
Depends on #83

[junha1]

Here's my idea of error handling in remote-trait-object

Why to handle

1. Communication protocol without an error handling is very weird.

2. Sandboxed modules are assumed to be arbitrary in their behavior.

3. Coordinator might want to retry the call, reboot the module, or report the error.

What to handle

1. Errors returned by TransportRecv and TransportSend.

2. Deserializaiton error

3. Protocol error (invalid object id, invalid method id, ...)

How to handle

Call fail

1. You can optionally use an error-handleable trait that is compatible with the original one.

2. In such special trait, all its methods will have Result<OriginalReturnValue, RtoError> by the macro.

3. Service implementor will never care of this, because error handling is completely optional in runtime, by the client side. Thus, Error will never be serialized and go through the transport.

Call handling fail

1. Errors will be reported to the Context.

2. The server might just ignore and retry to recv() and send() depending on the type of error