Add CocoaPods dependency manager

[pietbrauer]

analyzer: Add initial support for the CocoaPods dependency manager

Constructing the dependency tree for any given Podfile solely from the
output of the pod sub-commands requires running pod sub-commands
which only run on macOS. This implementation avoids all macOS-only
commands by constructing the dependency tree from the lockfile and
therefore the analysis of any Podfile requires the precence of the
corresponding Podfile.lock.

In order to obtain the meta-data for a dependency, the corresponding
.podspec file is determined via the command pod spec which. These
paths always point under ~/cocoapods/repos which is where CocoaPods
sets up its so called Specs repositories. Which repositories are to be
used is defined by the respective Podfile via the source property,
which defaults to [1]. This implementation disregards the specified
repositories and always assumes that default. That default specs
repository is however not used via GitHub, but via CDN as this is much
faster [2]. Cloning [1] takes 10-30 minutes and takes a bit more than
5GB while the CDN approach initializes in no time and fetches only
required data.

Even with that CDN based approach the implementation can
and should be extended to adhere to the specified repositories in the
future, see #4188.

[1] https://github.com/CocoaPods/Specs
[2] CocoaPods/CocoaPods#7046

------------------------------------- Original description from Piet below -----------------------------------

This PR adds CocoaPods as a dependency manager.

I tested it on macOS and inside the docker container. The Gem runs fine on Linux, the only thing that doesn't work is pod install because Xcode is missing. As far as I am concerned pod install is not needed, if the Podfile.lock is present.

Things I am unsatisfied with/didn't know better:

1. How to mock the Command invocations to test the actual flow
2. JSON parsing
3. Parsing the strings like Alamofire/Something (~> 1.0) into a PackageReference
4. I also don't like cloning the spec repo inside the docker container which takes about 5 Minutes and adds a lot of storage. Setting it up on demand is even worse, if you do it every time you launch the docker container.

Any pointers are welcome.

[sschuberth]

Thanks for the contribution! Unfortunately, at least I'd need a few more days before I could start looking at this.

[fviernau]

Hi @pietbrauer ,

thanks for your contribution! I'm picking up this review now - mind helping me with the below initial questions?

1. You mentioned "As far as I am concerned pod install is not needed, if the Podfile.lock is present.". Can you give me a hint
   why install is necessary if there is no lock file?
2. Regarding "I also don't like cloning the spec repo inside the docker container which takes about 5 Minutes and adds a lot of storage. Setting it up on demand is even worse, if you do it every time you launch the docker container." Have you considered the approach to not clone it initially but on-the-fly, and at the same time recommend the user to either (a) bind mount a host directory into the Docker or (b) use a Docker volume for that directory?
3. Have there been any higher level implementation / design decisions which you made, which aren't obvious from the PR description or commit (e.g. like choosing whether to parse lock files)? If so, mind sharing them e.g. in the PR description?
4. Do you know whether it's possible to make install work on linux?
5. Does the implementation have any known limitations, things it cannot handle.

[fviernau]

@pietbrauer In order move a bit faster, I've setup a branch [1] in this repository and pushed your changes (rebased onto master). I'll make some modifications to the code there (force push) and as soon as done we may create a new PR from that branch replacing this PR. Fine with you?

[1] https://github.com/oss-review-toolkit/ort/tree/cocoa-pods-support

[pietbrauer]

@fviernau I'm currently on parental leave and won't work on it until August. We have it in use at Porsche so we don't have time pressure.

I don't get the working on a different branch but if that's how you want to review it so be it.
I enabled that maintainers can push onto this branch so rebasing and committing should be possible without splitting all the work onto multiple PRs or branches I can't push to.

[fviernau]

@pietbrauer @sschuberth @mnonnenmacher

I refactored or re-wrote a couple of things mainly for simplification / clarity.
Therefore I

• dropped the previous unit tests in favor of functional ones, as I needed to get rid of implementation detail tests in
  order to enable the refactoring. The functional tests cover the cases Piet had covered before.
• I've addressed the points 2, 3 mentioned by Piet in the description.
  For 3, parsing version string of the form Alamofire/Something (~> 1.0) is not needed anymore as versions
  are now only taken from top level entries which never use that format including the tilde.
• Point 4 is addressed by not using the Github specs repo anymore, but the CDN repo.

I'd see Point 1 not as an issue anymore and I'd prefer to add the documentation in a follow up PR.

edit: I'm still working on the CI issues, so only the Kotlin bits are ready.

[mnonnenmacher]

Please also update the list of supported package managers in the README.

Addressed or commented on.