No other than reason than me looking at the CocoaPods setup and
realizing we were a few versions behind.

Despite it working during the prototype stage, I wasn't able to get the
XCFrameworks out of the ZIP archive, but it works fine with the tar.gz.

I suspect this has to do with the folder(s) generated when
decompressing.

These are unnecessary at the moment but will be when we move to
Gutenberg via XCFramework

The advantage of this approach is that downloading the archive is only
necessary when using a local spec. Defining the logic in the local spec
itself keeps everything self contained and saves us from having to
conditionally call the `pre_install` hook.

The idea was to use a local spec and interpolated the desired commit
SHA1 in the `source` to download the corresponding `tar.gz`.

However, CocoaPods has some issues with local specs that use `http`
`source`, as documented in:

- CocoaPods/CocoaPods#10288 (comment)
- https://github.com/firebase/firebase-ios-sdk/blob/68b39b8edf61f6e643e2396e712c7c67e0f146ff/scripts/pod_lib_lint.rb#L70-L78

Using a remote spec doesn't have the same issue, and the cost in terms
of extra computation and storage is negligible when compared to building
and hosting the `tar.gz` archives.

See
wordpress-mobile/gutenberg-mobile@57f9dd1

This was done to address the following CI failure when building with the
Gutenberg XCFramework:

```
▸ Linking WordPress
⚠️  ld: Could not find or use auto-linked library 'swiftCompatibility56'

❌  ld: symbol(s) not found for architecture x86_64
```

https://buildkite.com/automattic/wordpress-ios/builds/14356#01885545-c05a-43a8-b475-d0d683857672

Because the latest XCFramework setup ships without testing compilation.

Co-authored-by: Tony Li <tony.li@automattic.com>

Co-authored-by: Tony Li <tony.li@automattic.com>