[Fastlane.swift] Add formatter to Fastlane.swift

[minuscorp]

Checklist

• I've run bundle exec rspec from the root directory to see all new and existing tests pass
• I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
• I've read the Contribution Guidelines
• I've updated the documentation if necessary.

Motivation and Context

I've seen that the Swift codebase doesn't follow any lint rules nor common syntax rules, so the first step is to integrate Swiftformat to ensure that every API or external change gets linted properly into the codebase. This not makes conflict to propose changes or cleanup code as proposed by another members.

Description

Testing Steps

[jhandguy]

Awesome! 😍 Do you think it would make sense to add SwiftLint as well?

[minuscorp]

I just wanted a formatter, not a linter, if that difference makes sense. I just want to make sure that the code is following a set of common format rules and correct them if they fail (as Rubocop do) Swiftlint goes further with enabling and disabling rules and so on, I think it'll be too much for the project itself. What do you think?

[jhandguy]

Of course, I was not questioning the choice of the formatter, formatters and linters do serve different purposes and both are valid in a project. I was only raising the possibility of adding SwiftLint on top of SwiftFormat, which could lint things that a formatter does not handle such as function and file length, nesting, etc.
And since some of the Fastlane Swift files require to be imported in the project (i.e. SnapshotHelper.swift), developers might expect those to be linted via SwiftLint.
But that's just a thought 👍

[minuscorp]

The case is, the people will get the project already formatted into their Fastlane.swift, we do not force any rules because we do not embed the formatter into the project, just into the code that is being pushed. It is then user choice to make their own code changes, linting, etc. Any code that breaks is actually out of the organization, more of the user digging into the codebase 😛

EDIT: We let the user decide to lint the project or event add more format rules. We're just making babysteps to make the codebase more readable in different iterations 😄

[jhandguy]

Makes sense @minuscorp, thanks for the clarification 👌

[minuscorp]

My plans are to improve the Swift current codebase as much as possible in further PRs, but I have a wait list 😪 it will come 😈

[minuscorp]

@joshdholtz 👀 😄

[joshdholtz]

This is 🔥 Never crossed my mind to format this lol. Thanks for adding this in 😍

[fastlane-bot]

Hey @minuscorp 👋

Thank you for your contribution to fastlane and congrats on getting this pull request merged 🎉
The code change now lives in the master branch, however it wasn't released to RubyGems yet.
We usually ship about once a week, and your PR will be included in the next one.

Please let us know if this change requires an immediate release by adding a comment here 👍
We'll notify you once we shipped a new release with your changes 🚀

[fastlane-bot]

Congratulations! 🎉 This was released as part of fastlane 2.151.0 🚀