qbs.targetOS cannot (only) be a list

targetOS used to be a scalar before I started working on Qbs. After that, I changed it to a list, but this solution was only half-right.

Fast-forward to module merging and we're left with the situation where you can't actually usefully set qbs.targetOS in project files.

Because we've been moving away from profiles as being so fundamental, and more towards cacheable Probes and more intelligent Modules, the ability to set properties like targetOS within a Product becomes feasible, and it's actually necessary to support platforms like watchOS which require both an iOS and watchOS app in the same build tree.

We must continue to reject the notion that a single qbs build configuration or profile represents only a single ABI. In future even individual Products should be able to build for multiple ABIs at once (QBS-192).

Target triples for a given ABI themselves obviously only have a single "platform" component, but it's convenient to be able to identify target "families" like darwin and unix and bsd, which is why targetOS became a list. Users should ONLY use targetOS in their project files.

So, here's what should happen:

• qbs.targetOS becomes a read-only property. This should be fine with regards to backwards compatibility since setting it within a project file is basically useless at present, and command line invocations including this property are transient.
• A new scalar property must be introduced. This new property must be ONLY an input, and must not be read in user project files. Ideally we'd actually have the notion of "write-only" properties, but I have no idea how that would look or work language-wise. I originally conceived of this new property as simply a scalar OS value, but perhaps it could even reuse GCC/Clang's target triple concept, and qbs would parse this arbitrary input string to form other properties like qbs.architecture, qbs.targetOS, and so on. This would enable setting it in project files. However, retaining the ability to specify individual components is also important, and might make more sense as well for modules under which a notion of "targetOS" makes no sense. I wonder whether the architecture property being part of the qbs module makes any sense either, compared to going directly into cpp.