[objective_c] Collections support for NS[Mutable]Dictionary and NS[Mutable]Set

[liamappelbe]

NSDictionary and NSMutableDictionary now mix in MapBase, and NSSet and NSMutableSet mix in SetBase. The immutable variants just throw if the mutating methods are called.

The implementation is mostly straightforward. To make iteration easier, I also changed NSEnumerator to implement Iterator. That way, we can use the existing [key/object]Enumerator() methods to iterate the collections without having to add another layer of wrapping.

The one quirk is that NS[Mutable]Dictionary's keys must implement the NSCopying protocol, which means that on the Dart side we have a bunch of NSCopying objects in the API, instead of pure ObjCObjectBase. But the ObjC API isn't very type safe, so there are still a bunch of places where it uses ObjCObjectBase for the keys. So I had to do some castFrom calls, and add a _NSDictionaryKeyIterator that wraps the NSEnumerator and casts the elements as it's iterating.

Also, it turns out if a class extends Base and mixes in Mixin, the methods from Mixin will override any matching methods from Base. This means some of the methods on NSMutableArray were falling back to the slow versions on ListMixin, rather than using the fast versions from NSArray. So I had to duplicate some methods. Same logic applies to NSMutableDictionary and NSMutableSet.

Fixes #1444
Part of #1443

[github-actions]

PR Health

Breaking changes ⚠️

Package	Change	Current Version	New Version	Needed Version	Looking good?
objective_c	Breaking	7.1.0	7.2.0-wip	8.0.0 Got "7.2.0-wip" expected >= "8.0.0" (breaking changes)	⚠️

This check can be disabled by tagging the PR with skip-breaking-check.

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

API leaks ⚠️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbols
objective_c	_Version

This check can be disabled by tagging the PR with skip-leaking-check.

License Headers ✔️

// Copyright (c) 2025, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Unrelated files missing license headers

Files
pkgs/jni/lib/src/third_party/generated_bindings.dart
pkgs/objective_c/lib/src/ns_input_stream.dart

[coveralls]

coverage: 85.736%. remained the same
when pulling 350d7e4 on objc_map_set
into 7bca903 on main.

[HosseinYousefi]

Also, it turns out if a class extends Base and mixes in Mixin, the methods from Mixin will override any matching methods from Base. This means some of the methods on NSMutableArray were falling back to the slow versions on ListMixin, rather than using the fast versions from NSArray. So I had to duplicate some methods. Same logic applies to NSMutableDictionary and NSMutableSet.

Why do we have to re-mix-in(!) the ListMixin and others if they're already available in the class hierarchy? We can have NSArray with ListMixin and NSMutableArray extends NSArray and everything should be fine. There is no need to duplicate methods this way. NSMutableArray only overrides the existing modifying methods inherited from its superclass NSArray.

[liamappelbe]

Why do we have to re-mix-in(!) the ListMixin and others if they're already available in the class hierarchy? We can have NSArray with ListMixin and NSMutableArray extends NSArray and everything should be fine. There is no need to duplicate methods this way. NSMutableArray only overrides the existing modifying methods inherited from its superclass NSArray.

Oh yeah, I can just remove the mixin from the mutable versions. Why didn't I think of that 😅

It's a little more complicated for NS[Mutable]Array, since NSArray is an Iterable while NSMutableArray is a List (I think I misspoke in my earlier comment). So I went through the methods and checked the method implementations in ListBase. length is abstract so it should get it from NSList, elementAt delegates to [], and the addAll implementation is essentially the same as the one I wrote, so I can delete those 3 methods.