Support for @Native

[Dampfwalze]

Is your feature request related to a problem? Please describe.

Darts (experimental) native assets feature abstracts away the resolution and loading of binaries. They can be resolved using an asset id with the new @Native API:

@Native<Int64 Function(Int64, Int64)>('sum', asset: 'mylib/mylib')
external int sum(int a, int b);

flutter_rust_bridge still uses DynamicLibrary to load functions, which will not receive support for resolution of native assets, as described by dart-lang/sdk#49803 (comment).

Describe the solution you'd like

Regarding the eventual goal of native assets being one of the main methods to bundle binaries, I propose to generate bindings using @Native instead of DynamicLibrary. Maybe first behind an experimental feature.

Describe alternatives you've considered

There is currently no way to accurately resolve a shared library, bundled with native assets, in every scenario.

[fzyzcjy]

Sure! Indeed when developing the initial version of v2, I do think about this. However, it was (and still is?) experimental. Therefore, I want to wait a little bit until it is stablized. Or, do you have reasons to do it now (I am happy to hear!)?

There is no need to worry as an end user: This is just implementation details of flutter_rust_bridge, and when it is switched to the new API, users usually do not need to change things, and flutter_rust_bridge will just generate new code.