feat: add wrap option to macro to optionally generate wrapper types for enum variants

[Frando]

This adds an optional wrap attribute to the macro. When set, it will take the enum fields (can be any kind: unit, named, tuple), turn them into a struct, and modify the enum to have a single field as usually expected by irpc.

This reduces the boiler plate a lot for simple protocols. Also it allows you to skip the tedious newtyping if you e.g. have a lot of different requests that all take a single arg of the same type (e.g. a Uuid or a Hash).

It is purely optional, and works quite well with editors thanks to the span support (jump to definition jumps to the value of the wrap type, hover over that type gives the full fields, and jump to definition on a field of the generated struct takes you directly to the field on the enum variant even).

See the simple.rs example in the diff for the full boilerplatefree irpc-iroh galore.

I.e. it turns this

#[rpc_requests(message = FooMessage)]
#[derive(Debug, Serialize, Deserialize)]
pub enum FooProtocol {
    #[rpc(wrap=GetRequest, tx=oneshot::Sender<Option<String>>)]
    Get(String),
    #[rpc(wrap=SetRequest, tx=oneshot::Sender<Option<String>>)]
    Set { key: String, value: String },
}

into this

#[rpc_requests(message = FooMessage)]
#[derive(Debug, Serialize, Deserialize)]
pub enum FooProtocol {
    #[rpc(wrap=GetRequest, tx=oneshot::Sender<Option<String>>)]
    Get(GetRequest),
    #[rpc(wrap=SetRequest, tx=oneshot::Sender<Option<String>>)]
    Set(SetRequest)
}

#[derive(Debug, Serialize, Deserialize)]
pub struct GetRequst(String)

#[derive(Debug, Serialize, Deserialize)]
pub struct SetRequest  {
   key: String,
   value : String
}

[rklaehn]

So this is the most recent version? Tried it out, and seems to work fine.

Generation of the message enum is optional? What exactly does the macro do if you don't specify the message parameter?

I tried the no_rpc flag. It seems that the only thing the no_rpc flag controls so far is generating the remote service impl.

I tried the no_spans flag, but there are still spans in the enums. If we want to have no_spans at all, it should make sure that there are no spans in the enum cases.

Otherwise looks good. If @matheus23 likes it maybe I can get warm with the wrap flag, even though I will probably rarely use it myself.

[Frando]

This PR is on top of #46 and only adds the wrap option. I'll take your other comments over to #46.

[Frando]

Rebased on main now that #46 is merged

[rklaehn]

So, I gave this a quick try, and it does work as advertised.

Left a few comments regarding error messages.

This might be a nice option for people that don't like verbosity, but please let's not rewrite large protos like blobs in this style just yet.

There are various cases where having separate user-defined types for each case is way less confusing even if it is a few more LOC.

[rklaehn]

Since we now support named variants, this should be something like "unnamed variants must have exactly one field.

[rklaehn]

For the case where the wrap option is not set, and the enum case is a named case, we should probably mention the wrap option in the error.