[pigeon] Stop binding HostApi interfaces with jnigen: they're unused and make up 35% of the .jni.dart file #193882

Found while investigating #193195.

Summary

For each HostApi, pigeon asks jnigen to bind both the Kotlin interface (FooApi) and its Registrar (FooApiRegistrar). The generated Dart only ever calls the Registrar, so the interface's bindings are dead code. They are the single largest part of the generated .jni.dart file.

Details

• jnigen_config_generator.dart L127–132 adds '${api.name}' and '${api.name}Registrar' to the jnigen class list for every HostApi and FlutterApi.
• The generated Dart holds and calls only the Registrar (native_interop_tests.gen.dart L2707). Nothing in it references the bound HostApi interface.
• The FlutterApi interface is different: Dart implements it, so its binding is needed and should stay.

Measurements

From pigeon's test plugin, regenerated with jnigen 1.0.1 and formatted at width 100:

• The HostApi interface's bindings are 14,438 lines, 35.2% of the file.
• Without it, jnigen emits a 6-line stub for the Registrar's supertype, and the Registrar's own bindings come out byte-identical.
• The result passes the analyzer, and all 25 native interop probe calls pass in a release build.

Proposed fix

List only the Registrar for HostApis:

for (final Api api in root.apis) {
  if (api is AstHostApi) {
    indent.writeln("'$packagePrefix${api.name}Registrar',");
  } else if (api is AstFlutterApi) {
    indent.writeln("'$packagePrefix${api.name}',");
    indent.writeln("'$packagePrefix${api.name}Registrar',");
  }
}

The Kotlin interface stays as it is: the Registrar implements it, and users implement it. Only its Dart binding goes away. This is a patch-level change; plugins pick it up the next time they regenerate.

Benefits: smaller generated Dart (faster analysis, less code to ship and review) and less work for jnigen. No API or behavior change.