FFI-safe UI and related structures

Is your feature request related to a problem? Please describe.
Consider a program that wishes to enable development of plugins which could render their own UI within the parent app window. A concrete example would be a Digital Audio Workstation (DAG).

This maps well to egui architecture, as the plugin only needs &mut egui::Ui for most basic functionality. Passing &egui::Context as well would enable more, but isn’t necessary for an MVP.

The issue here is that Rust doesn’t provide a stable ABI out of the box.

Describe the solution you'd like
Make egui::Ui and all arguments of its methods repr(C) and FFI-safe.

Describe alternatives you've considered

1. Switching to a different tech stack — viable, but irrelevant for this discussion
2. Expressing UI in detached FFI-safe data structure and evaluating this within the main app. This works, but the inherent indirection makes the developer UX worse. Also, this doesn’t scale to widgets which the parent app doesn’t explicitly expose.
3. Only share a raw window handle and a rectangle, building another egui instance basing on that. There are some issues like passing the global state of dark/light mode choice or widget styling, but otherwise I think it’s a viable approach as well.

Additional Context
The abi_stable crate could do most of the heavy lifting AFAICT.

Open questions

• Is this feature in line with project goals?
• Support semver-compatible version mismatch, or only the exact same version?
• Performance implications? (I don’t think it’s a real issue, but I have not investigated this)
• Build time implications? If bad, is introducing another feature-flag justified?
• Even if useful, do the users care? If this brings little practical value, additional maintenance cost might not be worth it.

Start by auditing egui::Ui and the arguments of its methods to determine the scope of the ABI changes. Read the abi_stable crate documentation and assess the open questions around version compatibility, performance, build time, and feature flags. Done would require an agreed project direction and a defined, maintainable FFI-safe API.