iOS: Migrate PlatformViewsController to Objective-C

[cbracken]

This migrates PlatformViewController from C++ to Objective-C. Generally, we try to keep the embedder interfaces and components written in Objective-C except for the few places where C++ interfaces are requried to interface with engine APIs such as Shell and PlatformView (e.g. the PlatformViewIOS subclass). Now that the implementation is Objective-C, the class and file are renamed to match Objective-C naming conventions.

This allows us to take advantage of ARC and weak references, which eliminates the need for std::shared_ptr, fml::WeakPtr etc. Further, this eliminates some particularly unintuitive behaviour wherein this class was owned via a std::shared_ptr held by FlutterEngine, and injected into many other classes (e.g. AccessibilityBridge) via a std::shared_ptr& reference -- such that only one instance of the std::shared_ptr actually ever existed, presumably to avoid std::shared_ptr refcounting overhead. Given that this overhead was only incurred a single time at engine initialisation, this seems like overkill. One might ask why it wasn't therefore held in a std::unique_ptr and a std::unique_ptr& reference passed around. Likely, this was because we wanted to take a fml::WeakPtr reference on it.

Regardless, none of this is necessary any longer now that we can inject __weak FlutterPlatformViewsController* instances to classes that use it.

To be clear, this patch makes no attempt whatsoever to simplify or clean up the interface or implementation of this class. This class ties together far too many concepts and is injected into far too many places, and we should break it up and simplify it. However, the goal of this patch was simply to port to an Objective-C interface that plays nicely with the rest of the iOS embedder. This does include a couple minor cleanups in #include/#import order and usage to match our style guide.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[cbracken]

I'll delete this in a followup. This is just to keep things consistent for now.

[cbracken]

If we feel like, we could move this to a separate header, but this header is already internal so not particularly necessary/urgent.

[cbracken]

This will go in a followup. It's unnecessary. It's ordered here because oddly enough, it helped minimise the diff.

[cbracken]

Here and a bunch below: notice that the properties here are declared as reference types (std::unordered_map&), which allows for self.slices[foo] = bar rather than the underlying ivar type std::unordered_map, in order to avoid self.slices returning a copy.

This however, requires (a) manually declaring the ivar and (b) manually writing the getter.

These should eventually be migrated to Obj-C types like NSMutableDictionary*.

[cbracken]

@hellohuanlin Looks like renaming the file made the diff 100% diff instead of clear. Here's the version without the rename where you can see the diffs clearly:
https://github.com/flutter/engine/pull/56766/files

[hellohuanlin]

Will continue the review in https://github.com/flutter/engine/pull/56766/files