[swift2objc] Support Protocols

[nikeokoronkwo]

Closes #1828

From https://docs.swift.org/swift-book/documentation/the-swift-programming-language/protocols/#Protocol-Extensions:

A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. The protocol can then be adopted by a class, structure, or enumeration to provide an actual implementation of those requirements. Any type that satisfies the requirements of a protocol is said to conform to that protocol.

This pull request adds support for parsing protocols by achieving the following:

• Adding support for parsing basic protocols
• Adding parsing support for optional methods and properties
• Adding parsing support for conformed protocols (protocols that the given protocol inherits)
• Adding support for custom types in protocols via associatedTypes

• Writing tests that cover all given requirements

[nikeokoronkwo]

Extension support (#1815) might need to be added to implement default initialisation functionality

[github-actions]

PR Health

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?

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

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

[liamappelbe]

Extension support (#1815) might need to be added to implement default initialisation functionality

If there's a detail of this PR that will require a whole lot of extra effort to implement, just file a bug (or comment on an existing bug) and leave a TODO in the code to finish that work later. You don't have to do the whole feature in one PR. This means you can land your PRs quicker, and it also makes them easier for me to review because the individual PRs will be smaller and simpler.

[liamappelbe]

Is it possible to split out the AssociatedType stuff into a follow-up PR? I think that would simplify this PR a lot, and make it easier to review.

Does this PR do any new code gen, or is it just parsing at this stage? If it supports code gen, you'll need to add an integration test.

[nikeokoronkwo]

Is it possible to split out the AssociatedType stuff into a follow-up PR? I think that would simplify this PR a lot, and make it easier to review.

It is possible, but I felt that it was more of a stub than something that needed its own PR.

Does this PR do any new code gen, or is it just parsing at this stage? If it supports code gen, you'll need to add an integration test.

It will need some code gen, since protocols can be exported to Objective-C. However, during the gsoc period, I noticed ffigen didn't export Objective-C protocols, and I don't know the current state.

I'll try to work on both over the week. The new PR will give the opportunity to merge GenericType and AssociatedType under a common API (since AssociatedType is just a generic type specific to protocols)