Improve tuist generate speed by caching Swift version fetching

[adellibovi]

Short description 📝

Hello,
Currently every time a Target is generated we try to fetch what Swift version we have on the system.
This is an expensive operation since we need to execute an external shell command.
The impact can be easily seen when having a good number of targets.
In my tests, I've got tuist generate (release mode) to run from 20s to 13s, a nice 40% of improvement!

Update: got similar (or even better) results using tuistbenchmark for an existing fixture:

Fixture       : ios_app_with_tests
Runs          : 4
Result
    - cold : 0.76s  vs  1.14s (⬇︎ -0.39s -33.81%)
    - warm : 0.23s  vs  0.66s (⬇︎ -0.43s -64.98%)

and for a generated fixture: (fixturegen --projects 2 --targets 50 --sources 50):

Fixture       : generated
Runs          : 4
Result
    - cold : 2.19s  vs  5.11s (⬇︎ -2.93s -57.21%)
    - warm : 1.16s  vs  3.75s (⬇︎ -2.59s -69.01%)

Checklist ✅

• The code architecture and patterns are consistent with the rest of the codebase.
• The changes have been tested following the documented guidelines.
• The CHANGELOG.md has been updated to reflect the changes. In case of a breaking change, it's been flagged as such.
• In case the PR introduces changes that affect users, the documentation has been updated.

[luispadron]

Nice! Thank you for contributing 🚀

[pepicrft]

You might want to add some locks to prevent race conditions when accessing it from multiple threads

[adellibovi]

Nice catch, done! I noticed we have Atomic property wrapper in Tuist Support, that should do the work :)

[kwridan]

To help stress test this you could try generating a fixture with 50 projects :)

[fortmarek]

This is great to see, thanks!