RFC: Nested pods, gen transitive workspace via Podfile.lock

[jerrymarino]

This PR adds the ability to handle "child pods" within a pod. In cocoapods, its possible to provide a path within another pod, and this doesn't map to any notion we have. Simply put, it generates a BUILD file in the parent build, and aliases the Vendor/__POD__ to the parent directory.

Follow up changes to the RFC:

It adds the ability to generates a transitive workspace from a Podfile. I'm using this command to generate a Pods.WORKSPACE for transitive dependencies, specifically with react. It emits an output that can be used to paste into an existing workspace, or perhaps automatically import. I'm investigating at ways to call this command automatically

Additionally, add Yams. We'll have to default to Bazel and remove SPM as a separate PR. I needed to, version rules_swift for yams. Perhaps we can bump to latest as the bug we have here is fixed.

Generate new_pod_repository entries from a lockfile. I expect to automatically generate a dummy lockfile, and then import this some way

[jerrymarino]

Hey @rahul-malik , some of the latest changes in ReactNative don't map well to any idioms that we currently support here. This PR is my overall solution to handling child pods. It still needs a few more hacks and kinks worked out, but this is the general structure I've came up with for it.

Generating Pods.WORKSPACE from a Podfile workspace is somewhat tangential, but this code is useful to update react since there are so many child pods 💥 . I'm planning to polish that feature up and put it in another PR ( check out the synapsis for more info )

[jerrymarino]

This approach has a few thorns, that need to be addressed before merging, but I think the overall premises, and API is on point.

Cache invalidation.

These units are no longer atomic. This can be fixed but is probably not ideal

Adjacent pods

When there are 2 adjacent podspecs, cocoapods effectively merges these into a single file. This behavior is prominent in RN and FBSDK. If we run the compiler as 2 seperate processes ( 1 for each pod ), then it needs to read state either out of the podspec or parse the build file. It'd be simpler to do a batch approach here, which would simplify cache invalidation and complicate the workspace rules and python script. It needs more research to see if we can adjust the Bazel workspace rule to handle this.

[jerrymarino]

I'm going to split this out into distinct PRs, but wanted to have it all in one place to capture the strategy and overall scope of this. Here is a PR to handle the child pods: https://github.com/pinterest/PodToBUILD/pull/120