feat: add MethodCall::push_fd() for passing file descriptors (SCM_RIGHTS)

[lsjostro]

Varlink lets a method call carry file descriptors as ancillary data (SCM_RIGHTS),
referenced from the parameters by push order — but this crate had no client-side
way to attach them. This adds that.

API

let mut call = client.some_method(args);
let idx = call.push_fd(fd)?;   // -> 0, then 1, ... (push order == the index methods reference)
call.more()?;                  // or .call()/.oneway(); fds are delivered with the request

• MethodCall::push_fd(fd) -> io::Result<usize> (unix only). Dups the fd with
  F_DUPFD_CLOEXEC (caller keeps ownership of the original), queues it, and
  returns its push-order index.
• On send, queued fds are delivered with the request via a single
  sendmsg() + SCM_RIGHTS on the connection's socket; any bytes past the first
  sendmsg are written normally through the existing writer.
• Only socket-backed connections (Connection::with_address) support this; a
  reader/writer-pair connection has no socket for ancillary data, so push_fd
  returns io::ErrorKind::Unsupported.

Passing descriptors is part of the Varlink protocol; this lets a client talk to
services that accept them (e.g. handing over stdio fds).

Scope

Send-only. Receiving descriptors (server → client) is not implemented — it would
require recvmsg-based reading throughout the input path, and nothing needs it yet.
cfg(unix) only, matching the crate's existing platform split; libc is already
a unix dependency.

Tests

varlink/src/test.rs:

• test_push_fd_passes_descriptor: push an fd over one end of a socketpair,
  recvmsg() the other end, and confirm the descriptor arrives and refers to the
  same underlying pipe (write through the received fd, read it back).
• test_push_fd_requires_socket: push_fd on a non-socket connection returns
  Unsupported.

cargo test -p varlink passes.