Resolve the limitation of FFI-based plugins

[swift-kim]

FFI-based plugins (path_provider_tizen, shared_preferences_tizen, url_launcher_tizen) currently only work when running in the main isolate and require additional initialization to run in secondary isolates: #122 (review)

[bbrto21]

to solve this limitation, do we need re-implement plugins based on native?

[swift-kim]

No, we need to check how other platforms tackle this problem but I had not enough time to investigate.

[swift-kim]

• I tested path_provider_windows on Windows and it worked without problem on secondary isolates. I'm still not exactly sure how the Dart plugin registry for Windows is different from flutter-tizen's.
• generated_main.dart was not generated by flutter_tools even with Reland the Dart plugin registry flutter/flutter#79669 applied on Windows. I don't know why.
• Still Reland the Dart plugin registry flutter/flutter#79669 will land to the stable branch soon and it would be better to re-implement flutter-tizen's Dart plugin registry based on the official one. In fact its approach is not quite different from ours, but the main difference is that generateMainDartWithPluginRegistrant (equivalent of _createEntrypoint for Tizen) is part of the build graph.
• Consider adding implements: attributes to Tizen plugins' pubspecs. It's not quite necessary tho because the attribute doesn't do very much thing.

[swift-kim]

I'll test swift-kim/flutter-tizen@1ed4ee7 when the next stable Flutter version is released.

Related engine PR: flutter/engine#25496

[swift-kim]

The implementation of the third solution in flutter-tizen/flutter-tizen#177 (comment) can be found at: swift-kim/flutter-tizen@6fd8233

The commit should land after the next Flutter stable release.

cc @HakkyuKim

[HakkyuKim]

@swift-kim That was really fast! Thank you!
I'll have a closer look tomorrow.