fix(cli): generate binaryTarget entries for custom xcframeworks in Package.swift

[OS-ruimoreiramendes]

When Capacitor CLI generates a Package.swift for a Cordova plugin in SPM mode, custom .xcframework files declared via <framework custom="true" src="..." /> in plugin.xml were not being translated into binaryTarget entries. The xcframework was already being copied to the correct location by copyPluginsNativeFiles, but the generated Package.swift had no reference to it, causing build failures.

This PR adds binaryTarget entries and the corresponding target dependencies for each custom .xcframework found in the plugin's plugin.xml.

Reference https://outsystemsrd.atlassian.net/browse/RMET-5155

[jcesarmobile]

RMET-5155 is about both .xcframework and .framework, this seems to only handle .xcframework.
Not sure if .framework aren't compatible with binaryTarget or if you missed that.
If they are not compatible we should warn some message if .framework files are present as the plugin won't work.

[OS-ruimoreiramendes]

RMET-5155 is about both .xcframework and .framework, this seems to only handle .xcframework. Not sure if .framework aren't compatible with binaryTarget or if you missed that. If they are not compatible we should warn some message if .framework files are present as the plugin won't work.

Regular .framework bundles with custom="true" are not supported by SPM's binaryTarget, only .xcframework is. I'll add a logger.warn to inform the developer when a custom .framework is found, since they'd need to convert it to .xcframework for SPM compatibility.
Also, I'm planning to push the RMET-5154 changes (system frameworks - linkerSettings) to this same branch, since both tasks are related to framework handling. Let me know if you'd prefer a separate PR for that.

[jcesarmobile]

I prefer to keep them separate

[OS-pedrogustavobilro]

I've been testing different apps and everything seems to be working, leaving a couple of comments though, but nothing major I think.

[OS-pedrogustavobilro]

I reckon probably as this method may grow, we may want to split it in a few ones, e.g. one to get the xcframework(s) and binary target, another to write Package.swift, and stuff like that.

But doesn't necessarily need to happen in this PR.

[OS-ruimoreiramendes]

makes sense, I can do it in this PR.

[OS-ruimoreiramendes]

done, take another look when you can

[jcesarmobile]

Since we will need to add more entries to the Package.swift(csettings, resource files, etc.), I would rather not have the writeGeneratedPackageSwift method as we will have to keep adding more and more params.
Or if we have it, it should have the methods for getting the texts inside instead of as params, i.e. for this PR, buildBinaryTargetEntries should be inside writeGeneratedPackageSwift to get the texts, rather than being called before to pass the texts as params.

[OS-ruimoreiramendes]

Makes sense, moved buildBinaryTargetEntries inside writeGeneratedPackageSwift so that as more entries are added in future PRs, they can be handled there directly without growing the parameter list.
I'll apply the same for #8448 as well. Depending on which PR gets merged first there may be a conflict, but it should be straightforward to resolve.

[OS-pedrogustavobilro]

Tested again, working great here!

[alexgerardojacinto]

Minor: I think the PR title should be fix(cli):...