Implement Transferable for anything that is Serialize + Deserialize

[hgzimmerman]

Anything that is Serialize + Deserialize<'de> will implement Transferable. Implementing Transferable will mark the struct or enum as a valid agent input or output type.

I think either this or #319 should be merged, as either broadens the set of types that can be sent between Agents and the rest of an application. Either of these PRs should allow types defined in other crates to be be Agent::Input or Agent::Output as long as they implement the Serde traits without having to "newtype" them. This allows () to be Input or Output, which is nicer than having to define a Void empty-struct that implements Transferable to represent the same thing.

The particular drawback of this change is that if you have a type that should not be an agent input or output, but is Serialize + Deserialize<'de>, it would be allowed as an Input or Output. As far as I'm aware, things that shouldn't be sent (like tasks) don't implement the Serde traits, so this wouldn't allow any behavior that is currently prohibited for safety reasons. Going on, the inability to implement Serialize + Deserialize<'de> for non-agent-message-same types would remain as a design constraint.

[therustmonk]

@hgzimmerman I often think about it. It's reasonable, but I used Transferable trait for two reasons:

1. actix uses similar approach and I think to use actix-core in the future
2. it may need more restrictions on the future. The trait can help us

But, maybe, it's useful to remove Transferable for now. Keep this PR open, I will match it with a potential moving to actix and let you know.

[hgzimmerman]

I wasn't aware about the use of something like the Transferable trait originating in actix, and maintaining parity with that makes a great deal of sense if that is ultimately the direction that Yew is moving towards.

I do think that because of how minor the complaint that these PRs addresses, the similarity to actix trumps the small ergonomic benefit proposed here.

[kellytk]

@deniskolodin

1. I think to use actix-core in the future

As I mention in #272 (comment), another option for your consideration is Riker. Regardless of which actor framework you use, I think it's a good idea to converge components with the actor model/ECS.

[jstarry]

Closing in favour of #319