[ffigen] Convert objects to extension types

[liamappelbe]

The jnigen bug has context: #1634. If it makes sense there it makes sense here.

It would be good to land this in ffigen 20 if possible, but I consider it a stretch goal.

[liamappelbe]

Notes:

• Static methods are totally fine, and will work the same as they do now.
• is doesn't work for extension types, but this is fine because it was already dangerous to do this for ObjC classes. The advice remains to use Foo.isInstance. Rename .isInstance to .isA to be more consistent with JNIgen and JS interop.
• as currently doesn't work for our ObjC classes, but it would work after the switch to extension types. Foo.castFrom would internally do an isA check, then convert the type using as. Rename .castFrom to .as to be more consistent with JNIgen.
• We'd be extending the ObjCObjectBase type, so all the memory management infra would remain more or less the same. ObjCObjectBase's constructor will still increment the ref count and set up the finalizer. But interestingly, since constructing the extension type doesn't create a new object, it doesn't increment the ref count. So there's fewer actual references from Dart to ObjC. This makes it a bit more efficient in some cases (eg type casting).
• As discussed on the JNIgen bug, the collections will no longer directly implement the corresponding Dart interfaces. Instead we'll move the adapter methods to a separate adapter class, and provide a method to construct the adapter from the ObjC object.
• The syntax for casting a raw pointer to a wrapper becomes more verbose (Foo(ptr) -> Foo(ObjCObjectBase(ptr)) or ObjCObjectBase(ptr) as Foo), but this is a very niche use case, so it doesn't matter too much.
• ObjCObjectBase is going to be a slightly more visible class now, so it's probably a good time to rename it, as I've always thought the name was too long. I'll change it to ObjCObject.

[dcharkes]

• As discussed on the JNIgen bug, the collections will no longer directly implement the corresponding Dart interfaces. Instead we'll move the adapter methods to a separate adapter class, and provide a method to construct the adapter from the ObjC object.

For the naming of the conversions, maybe we should try to be consistent with dart:js_interop https://api.dart.dev/dart-js_interop/JSStringToString/toDart.html (Though, if I remember correctly @srujzs mentioned that it's hard to understand to have sometimes toDart mean deep copy, and sometimes adapter.)

[HosseinYousefi]

• as currently doesn't work for our ObjC classes, but it would work after the switch to extension types. We wouldn't need Foo.castFrom anymore.

Maybe you still want to have a castFrom (in jnigen it's .as) that checks if the cast can be successful in obj-c.

[srujzs]

re: is and as, we have a lint to warn users from doing potentially dangerous runtime checks with JS interop: https://dart.dev/tools/linter-rules/invalid_runtime_check_with_js_interop_types. We redirect users to use isA (a helper that does an interop type check) instead.

toJS and toDart are just "easy" to remember for every type, but you're right that sometimes it may obfuscate the semantics, so it's something to consider before tying yourself to that naming scheme. They're also getters, even though the Dart-y recommendation is to make them methods, because we figured saving the () on every single call was worth it. That does mean though that they're less extensible. For example, we had to add toJSCaptureThis for functions instead of just extending toJS to take an extra optional parameter.