Provide an API for attachments in shared memory

[asajeffrey]

Currently most messages are serialized and deserialized using serde, which means that large messages are copied twice. This is possibly expensive, especially for messages which are being forwarded, ore do not need to be stored on the head (e.g. image data being loaded into a GL texture doesn't need to be first copied into main memory).

Currently there are two special cases: sending channels over channels, and BytesSender. It would be nice if we could generalize this to allow large types to be allocated in shared memory and serialized as an attachment with just the reference to shared memory.

[asajeffrey]

This came up in conversation with @jdm and @pcwalton.

[asajeffrey]

There are traits in https://github.com/asajeffrey/shared-data/ and https://github.com/standard-ai/interprocess-traits for data that can be safely sent and referred to in shared memory, which could be used as the basis of "types that can be added as attachments". cc @lovesegfault @nagisa

[asajeffrey]

Related: #126, #138 and #156

[asajeffrey]

It would also be nice to do this and maintain interop with serde's Serialize and Deserialize traits, since those have quite wide support in third-party crates. In particular if there is a third party Container<T> type with #[derive(Serialize, Deserialize)], it would be nice to be able to use that with attachments. So this probably means we can't intoruduce a trait SerializeWithAttachments: Serialize with support for attachments (and ditto deserialize).

[lovesegfault]

cc. @Ekleog