Device event attributes

[dNechita]

PR Description

See discussion #1368 (comment).

Things left to do in this PR:

• Update C#, C++ and Python bindings

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have commented new code, particularly complex or unclear areas
• I have checked that I did not introduce new warnings or errors (CI output)
• I have checked that components that use libiio did not get broken
• I have updated the documentation accordingly (GitHub Pages, READMEs, etc)

[rgetz]

I’m not convinced that the right abstraction here is something that simply exposes an interface where the user must poll for events. (it's better than what exists today, but still doesn't match what the normal use case is).

In the Linux IIO subsystem, events are conceptually hardware-driven notifications (threshold crossings, data ready, buffer watermarks, etc.), not just another value to periodically check. For example, the kernel exposes event channels that deliver timestamped events through a character device once they are enabled via sysfs.

Typical workflow (per the sysfs-bus-iio ABI):

• Enable the event through sysfs /sys/bus/iio/devices/iio:deviceX/events/<event>_en
• Wait for the event on the device node (/dev/iio:deviceX)
• Read the event structure once the file descriptor signals readiness.

This is inherently event-driven, not just attribute polling.

IMHO - what this means is we need a push model (iiod needs to push something to the connected clients) - not a pull model (where clients continually poll).