Bundle: Update ResourceRules to match those observed in an iOS package

[qmfrederik]

I've noticed that the resource rules which are generated do not match those observed in an iOS application bundle.

This PR:

• Updates the resource rules to match those seen in frameworks embedded in the WebDriverAgent
• Adds a unit test which uses the Signer to generate the _CodeSignature/CodeResources asset, and compare its output with those of the asset generated by the default tooling

[qmfrederik]

@filipnavara The unit tests currently download a version of the WDA from the releases page (at https://github.com/appium/WebDriverAgent/releases/tag/v4.10.10). There are other ways to acquire this package:

• Via the appium-webdriveragent npm package
• Adding it to the git repo
• Via the Quamotion.WebDriverAgent NuGet package, though that package is no longer maintained

Any preferences?

[filipnavara]

I'll need to look into this a bit. I remember already comparing the exclusion lists with the ones produced by Apple tooling. There could have been a difference in order but semantically they should have already matched (unless I missed some obscure case).

As for the WebDriverAgent package I am generally fine with any solution as long as it's cached (ie. the download is not performed for every test run). If you don't expect to update the package often then storing it in git is an option but binary files in git are generally a royal inconvenience (versioning them grows the repo size disproportionately; GitVersioning needs full history; in turn GitHub Actions get progressively slower).

[filipnavara]

I remember looking into the order earlier and deciding not to enforce it. The reason was some implementation detail of the Apple tooling that I cannot remember anymore (possibly that the order of properties is side effect of how NSDictionary orders things; in case of the exclusion list it was a deduplication of code using the same rules for V1/V2).

Here's the relevant part of Apple code: https://github.com/apple-oss-distributions/Security/blob/e4ea024c9bbd3bfda30ec6df270bfb4c7438d1a9/OSX/libsecurity_codesigning/lib/bundlediskrep.cpp#L589-L689

The order matches neither mine nor yours. While I consider the order to be generally unspecified for dictionaries / hash tables, in this specific case it seems that the keys are sorted as ordinal strings. I would prefer to do that explicitly by adding a sort instead of trying to match the order manually.