Fix current door_call interface

[robertdfrench]

The current door_call interface is sortof busted -- it doesn't handle rbuf correctly, or cleanly.

I think we need a DoorArgumentsBuffer type which has a to_door_args() method that will emit the current type. That way we still can have a single thing to own each of these buffers -- if folks don't want or need to use that, they can construct a door_args_t themselves.

If rbuf.ptr() doesn't match the storage allocated for rbuf by the DoorArgumentsBuffer, then somebody will need to deallocate the old rbuf (since it wasn't used) and munmap the new rbuf (since it was mapped into the client's address space by the kernel) once it is no longer needed.

Originally posted by @robertdfrench in #6 (comment)

[robertdfrench]

Alternatively, multiple separate door_call routines:

1. The real one, which takes a door_args_t
2. one that takes only data and returns a "Door Payload" type (data and descriptors)
3. one that takes and returns a "Door Payload" type
4. one that takes a Door Payload type and designates a buffer for the return payload to be written

Somehow the return type should know that it needs to check itself against the rbuf pointer and call dealloc if necessary. For cases 2 and 3, the underlying door_call should be issued with rbuf pointing to NULL, so that the operating system always maps any returned memory into the address space for us.

[robertdfrench]

This includes #4

[robertdfrench]

0f2156f does not do anything to resolve this, because if the server were to return memory to the client, it would never get unmapped.

[robertdfrench]

The trouble is that DoorArgumentsBuffer sounds like a buffer for the data, which it may not be. It just need to own the rbuf. Maybe it should be DoorArgsWithReturnBuffer or BufferedDoorArg

[robertdfrench]

Fixed in #31

[robertdfrench]

This is still marked as broken in the documentation.