Establish a straight-forward relation between a RunConfiguration and "its" BuildConfiguration

[Terminology: BC - BuildConfiguration, BS - BuildSystem, DC - DeployConfiguration, RC - RunConfiguration]

Currently, an ("old") Target has zero-or-more BCs, one-or-more DCs and one-or-more RCs which can be combined arbitrarily by the user. However, this is conceptually wrong: A BC defines what is actually build, and consequently what could be deployed and run. Also, a RC 'its' BC data using target()->activeBuildConfig() gets wrong (or no) data when the user switched build configs in the mean time.

Idea here is to associate the "real" BC with the RC by restructuring the hierarchy.

Current thinking is to keep a Target as wrapper around one BC and its DCs and RCs, but have more such ("new") Targets, as many as there where previously BCs in the target,  see Option 2.

Alternatively, the Target layer could be removed completely and e.g. BC take its role (see Option 3). Bike shedding is

UX related to keeping RCs (and DCs) in sync across BC of the same (old) Target

Right now that's effectively "build in", without no-one complaining. We could have some user-visible setting per BC (on by default) to keep that behavior and silently keep data in sync (or truly "share" RC's???). When the user opts out, he's on his own.

Settings file contents migration

The structure of the settings is currently 

   Target  ( BCs ( BC1, BC2, ..., ) , DCs ( DC1, DC2, ..., DCn), ... )

New could be

   NewDingens ( BC (BC1, BC2, ...) , DC1, ... )

    ....

   NewDingens ( BC (BC1, BC2, ...) , DCn, ... )

(with a $n NewDingens instead of the original 1 Target with $n build configurations)

If we used the functionally equivalent

   NewDingens ( BC (BC1, BC2, ...) , DC ( DC1 ) , ... )

    ....

   NewDingens ( BC (BC1, BC2, ...) , DC ( DCn ), ... )

(i.e. a fixed single DC, but still in a DCs container) this could be read by older versions of Creator. On the other hand, the old format could be read $n times (with rest dentically repeated), which would also create the right context in case of "synced" RCs/DCs (i.e. the proposed default).

Implementation

Options 1, 2 and 3 are functionally equivalent, 1 is closest to current structure. Going to 1 is /not/ mechanical. Going from 1 to 2 is mechanical and won't touch any user code, Going from 2 to 3 is also mechanical, but would touch a lot of user code. We go Current -> 1 -> 2 -> 3 but also stop after 1 or 2.

Slightly related would be a  merge *BS into corresponding *BC, which would simplify some code on both PE and user side. Reason: *BS and *BC are parallel hierarchy, not really needed, and complicate user code at times. Mostly historical reasons (what is in *BS used to be part of *Project). Alternative view: BC is a "static" description of the build properties, whereas BS is the dynamic part including the parser and parsing results. The change would be mechanical. but move quite a bit of code around. Normal order of operations for this activity:

• Merge *buildconfig and *buildsystem files
• Make sure function names are disjoint
• Merge class definitions
• Make it compile again

To be continued [...]