[feedback wanted] refactor: Limit BuildSettings usage to only String and [String] values

[waltflanagan]

In working on tuist/XcodeProj#903 i've found that build settings defined in project files are always deserialized and String and [String] types. Other types like Bool or Dictionary are not representable within build settings. Even for boolean settings, Xcode encodes and decodes the strings "YES" "NO".

Secondarily, there are some things within BuildSettings.swift that are specific to tuist behavior like default build settings for mergable libraries, and scheme generation. I'm not sure how these are intended to be used but as they are not part of a standard xcodeproj I don't believe we want to be attempting to read tuist value that are put into build settings.

Opening this PR to start a conversation on the path forward related to these two topics.

[fortmarek]

Other types like Bool or Dictionary are not representable within build settings. Even for boolean settings, Xcode encodes and decodes the strings "YES" "NO".

I'd preserve the helpers from String to a specific type. I can see these being broadly useful. But yeah, otherwise, they should be represented as String as those conversions to specific types can be lossy.

Secondarily, there are some things within BuildSettings.swift that are specific to tuist behavior like default build settings for mergable libraries, and scheme generation. I'm not sure how these are intended to be used but as they are not part of a standard xcodeproj I don't believe we want to be attempting to read tuist value that are put into build settings.

Long-term, I'd like us to remove any Tuist specific pieces from XcodeGraph. XcodeGraph should be setup-agnostic and not Tuist-specific. So, if we can, I'd like us to look into removing these completely.

[waltflanagan]

@fortmarek do you think the YES ->true conversion should live in XcodeGraph or as another case on BuildSetting in XcodeProj? we could include decoding those values into bools there instead.

[fortmarek]

do you think the YES ->true conversion should live in XcodeGraph or as another case on BuildSetting in XcodeProj? we could include decoding those values into bools there instead.

Since we have some convenience methods for this in XcodeProj, it could probably live there instead of here.

[waltflanagan]

@fortmarek i ended up with this: tuist/XcodeProj@082545a

I think it's a good compromise keeping the raw representation strict to what is read/written but allows things like settings["ENABLE_TESTABILITY"] = true and if settings["ENABLE_TESTABILITY"].boolValue == true for consumers.

[waltflanagan]

Continuing this in #147