Improve Tuist project declaration

[pepicrft]

Short description 📝

The schemes setup in the generated project required developers to switch to a scheme to run a particular acceptane test. This is something that I found slightly annoying, so I went ahead and iterated on our schemes list. I disabled the automatic generation of schemes, which is fine for 90% of use cases, but we've reached a point when we need something more custom. Note that I considered the idea of making automated schemes more configurable, but I think it's a bad idea because the configuration interface will end up being complex and we'll start getting request along the lines of "can you also extend automatically-generated schemes to allow me to do X, Y, and Z?".
I've also taken the opportunity to embrace a new pattern where our modules are cases in an enum, and we can then use allCases and attributes to get the list of targets that we are interested in. That leads to a leaner Project.swift, and also a project that's easier to reason about.

How to test the changes locally 🧐

You should see schemes for the runnable targets (tuist, tuistfixturegenerator, and tuistbenchmark) and a workspace one that contains everything. They should all compile and run tests fine.

Contributor checklist ✅

• The code has been linted using run mise run lint: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