Switch static xcframework rule to produce framework

[keith]

Previously the apple_static_xcframework rule produced a xcframework that
wrapped a static library. This change makes it produce a static
framework instead. A static framework has the benefit that headers are
easier to deal with in 2 ways (at least when including with bazel):

1. You don't need to set any includes on the import, reducing -I
   flags up the tree (since they're covered by the -F instead
2. Module style imports #import <foo/foo.h> are supported without any
   other infra, with libraries only quoted imports work without
   headermaps or another solution

The reason this wasn't done originally is that Xcode doesn't support
copying resources in static xcframeworks. While this is the same with
libraries and frameworks, the difference is users might expect resources
nested in framework bundles to be copied, but they will not be, and
users may expect that in the static library case, since libraries don't
ever manage resource inclusion. It sounds like CocoaPods handles this
transparently, but Xcode does not FB10026748.

[keith]

not sure if we should do this or not, at Lyft some of our libraries require this or another solution to imports which we've never had to do before since we don't have much objc, maybe other folks wouldn't be phased by that.

[lyft-lint-bot]

Lyft integration job started: https://buildkite.com/lyft/rules-apple/builds/632 (must be Lyft employee to view)