Stateless target properties

[lhstrh]

In response to feedback from @cmnrd, this PR simplifies the dealings with target properties further, by eliminating the TargetProperty enum. This will also make it easier in the future to accommodate a plugin architecture where plugins can contribute target properties. It is also a step into the direction of handling options within target properties as target properties themselves.

Tasks remaining:

• Fix unit tests
• Split contents of TargetProperty between TargetConfig and AbstractTargetProperty
• Rename AbstractTargetProperty to TargetProperty

[cmnrd]

I like the general direction this takes, but I still feel like we are missing something.

In the current implementation, the TargetConfig class registers all the properties. Then we have to later figure out if they are supported by the target or not and also apply target specific validation (like with the tracing property).

Maybe we should just let the target generators register their supported properties. GenreatorBase could have a method registerTargetProperties that registers all the basic properties that are supported by all the targets. This method could be extended by the target generators to register target specific properties. In consequence, only supported properties are registered. This would fix several of the issues that we have discussed:

• The targets are responsible for deciding which properties they support (Refactoring of target properties and their validation #2008 (comment))
• Different targets can register different properties for the same name. I.e., the C++ generator can register a Boolean property for "tracing", while the C target registers a dict property. (Refactoring of target properties and their validation #2008 (comment))
• It becomes trivial to detect situations where a target reads a property that it did not declare as supported (Refactoring of target properties and their validation #2008 (comment)). Reading a property that is not registered should throw an exception.

[lhstrh]

Maybe we should just let the target generator register their supported properties. GenreatorBare could have a method registerTargetProperties that registers all the basic properties that are supported by all the targets. This method could be extended by the target generators to register target specific properties. In consequence, only supported properties are registered. This would fix several of the issues that we have discussed:

Right. This is what we should do. Thanks for the thoughtful reviews and nudging this refactoring into the right direction, @cmnrd and @oowekyala!