optee-teec: refactor plugin support

[ivila]

• Introduce optee-teec-plugin-bindgen crate to generate plugin bindings for plugin developers, replacing optee-teec-macros.
• Refactor optee-teec::PluginParameters and add additional methods.
• Update optee-teec-sys::PluginMethod to latest version.

With these changes, plugin development now only requires adding optee-teec-plugin-bindgen as a build dependency and including the generated artifact in lib.rs.

Why not use a proc macro?

I have thought about implementing a declare_supp_plugin macro like thisdemo:

declare_supp_plugin!(
    name: "my_plugin",
    uuid: "ef620757-fa2b-4f19-a1c4-6e51cfe4c0f9",
    init: my_init,
    invoke: my_invoke,
);

Developers can use it like:

use optee_teec::{declare_supp_plugin, PluginParameters};

fn plugin_init() -> optee_teec::Result<()> {
    println!("*plugin*: init, version: {}", env!("CARGO_PKG_VERSION"));
    Ok(())
}

fn plugin_invoke(_: &mut PluginParameters) -> optee_teec::Result<()> {
    println!("*plugin*: invoke");
    Ok(())
}

declare_supp_plugin!(
    name: "syslog",
    uuid: "ef620757-fa2b-4f19-a1c4-6e51cfe4c0f9",
    init: plugin_init,
    invoke: plugin_invoke,
);

The main issue is that developers may provide the UUID through a variable. Due to the limitations of proc macros, we cannot resolve the value of that variable during macro expansion. As a result, the UUID would need to be parsed and converted at runtime.

declare_supp_plugin!(
    name: "my_plugin",
    uuid: proto::PLUGIN_UUID,  // proc_macro cannot resolve the value at compile time.
    init: my_init,
    invoke: my_invoke,
);

However, this introduces another problem: what happens if UUID parsing fails? Triggering a panic in a shared library is not a good idea and should be avoided.

[DemesneGH]

I see why we're avoiding macros, but using strings for function names is a bit weird.
Since most users don't need custom names anyway, how about using defaults like plugin_init and plugin_invoke? Then the default constructor only requires the name and UUID. This would clean up the API and eliminate potential typos in build.rs.

We can also provide one more constructor that accepts the customized fn name if you'd like to.

[ivila]

Sounds good!😃