Add --additional-parameters option to passthrough following arguments/options/flags to the xcodebuild invocation

[stephanecopin]

Add the --additional-parameters option as a first step towards solving #5080.

Short description 📝

Add a new --additional-parameters to tuist test, allowing to pass any arguments/options/flags to xcodebuild. The approach used here was briefly discussed in the slack thread here.

How to test the changes locally 🧐

1. Run tuist test --additional-parameters -dry-run on any project and verify that the xcodebuild command actually does a dry run and doesn't do any testing.

Contributor checklist ✅

• The code has been linted using run ./fourier lint tuist --fix
• The change is tested via unit testing or acceptance testing, or both
• The title of the PR is formulated in a way that is usable as a changelog entry
• In case the PR introduces changes that affect users, the documentation has been updated

Reviewer checklist ✅

• The code architecture and patterns are consistent with the rest of the codebase
• Reviewer has checked that, if needed, the PR includes the label changelog:added, changelog:fixed, or changelog:changed, and the title is usable as a changelog entry

[danieleformichelli]

When is this needed? In general, I would like low level details to not be exposed on tuist CLI

[stephanecopin]

@danyf90 that's a fair question! So it could be needed for running or skipping tests using -only-testing or -skip-testing, or to use -only-test-configuration/-skip-test-configuration when test plan supports is implemented (that's my next PR after this one).
Rather than having to mirror each flags that could be used with testing within xcodebuild in Tuist (which could become quickly hard to maintain), we allow the user to specify whatever flags it wants and they'll get passed-through as-is to the xcodebuild invocation. While it does expose some implementation details (of Tuist using xcodebuild), I do think it's a necessary evil because of how many options can be used for unit testing.
It would also future-proof tuist test as we won't need to update Tuist when xcodebuild adds more options.

It was briefly discussed on slack here and there, and other people agreed with the approach. Happy to discuss it further in the latter thread if needed.

[danieleformichelli]

Replaced by #5135