i2c: phase 4 — WaitGroup interrupt loop + slave notification dispatch

Replace the single-channel object_wait with a WaitGroup that multiplexes
two sources on the i2c_server main loop:

  user_data=0  IPC from client  (Signals::READABLE on handle::I2C)
  user_data=1  I2C2 hardware interrupt (signals::i2c2 on handle::I2C2_IRQ)

Server startup registers both sources once via wait_group_add, then
calls object_wait(WG, READABLE, Instant::MAX) as the single blocking
point. When the WaitGroup fires:

  • user_data 1 (interrupt): call drain_slave_rx() for every
    notification-enabled bus, interrupt_ack() the IRQ, then
    raise_peer_user_signal() to wake the registered client.

  • user_data 0 (IPC): dispatch as before; two new ops added:
    - EnableSlaveNotification  → backend.enable_slave_notification()
    - DisableSlaveNotification → backend.disable_slave_notification()
    SlaveReceive now calls get_buffered_slave_message() (non-blocking)
    instead of the 10 000-iteration poll loop.

system.json5 changes (both i2c-slave and i2c targets):
  - Add I2C2_IRQ interrupt object (IRQ 112, name "i2c2")
  - Add WG wait_group object

channel_read/channel_respond remain synchronous: by the time the
WaitGroup fires with user_data=0 the channel is already READABLE, so
channel_read returns immediately without blocking.