portal_devfs: blocking poll for plugin-backed char devices (fix #77)

[lacraig2]

Summary

Fixes #77. A from_plugin-backed /dev char device could not block a
poll()/select() reader. igloo_convert_ops_to_fops() wired the devfs poll fop
straight to the Python-modeled poll (out->poll = ops->poll) and the driver never
called poll_wait(), so there was no wait queue for a "not ready" poll to sleep on:

• a data-aware poll reporting "not ready" had nothing to block on, and
• the legacy always-ready poll made poll()->read() readers busy-loop on 0-byte
  reads — pinning a core under TCG.

(Companion to rehosting/penguin#843, which adds the data-aware poll on the Python side.
With both, a from_plugin serial-style device delivers responses to a blocked reader
with no idle spin.)

Change

src/portal/portal_devfs.c:

• struct portal_devfs_entry gains wait_queue_head_t poll_wq plus python_poll /
  python_write (the Python-modeled fops, kept so the proxies can forward to them and
  the block path can call them directly).
• igloo_devfs_proxy_poll() — recovers the entry via container_of(inode->i_cdev),
  calls poll_wait(file, &pe->poll_wq, pt), then defers the readiness mask to the
  Python poll. Falls back to the legacy always-ready mask when no Python poll is modeled,
  so existing always-ready nodes are unchanged.
• igloo_devfs_proxy_write() — forwards to the Python write, then
  wake_up_interruptible(&pe->poll_wq). A write commonly queues a response on the host
  side (request/response serial devices), so a reader blocked in poll() is woken
  promptly instead of waiting out a poll timeout.
• out->poll/out->write are routed through these proxies; the entry is created with
  init_waitqueue_head(&pe->poll_wq) and the captured Python fops.
• The block queue_rq path calls python_write directly (it has no struct file),
  bypassing the char-only write proxy.

Behavior

• No Python poll modeled → always-ready mask (unchanged from today).
• Data-aware Python poll (returns POLLIN only when data is queued) → a reader blocks in
  poll() when idle (no spin) and is woken by the next write that queues a reply.

Testing notes

Not yet built in CI from this branch / not runtime-tested in the combo with penguin#843
(no kernel-devel in my working tree). The change mirrors the existing proxy_release
pattern (same container_of/forwarding shape and the same unsigned int poll signature
that out->poll = ops->poll already used). Reviewers: please confirm the CI module build,
and the end-to-end behavior with penguin#843's data-aware poll.

Follow-ups

• write_iter is not proxied (no wake) — add if a backing models it.
• An explicit host-initiated wake (a portal op the backing can call after queuing
  unsolicited data, e.g. modem URCs) would cover the async case; wake-on-write covers
  the request/response pattern.