A built-in item config module

It would be nice to have a module to control the default behaviour of built-in items such as Application and Library.
Right now, it is impossible to choose between the default library (static/dynamic) type without writing a "buildconfig" module as shown in the tutorial
While writing such a module has some advantages (users are in full control of the module and toolchain and can set e.g. cpp flags in the module), it is not convenient to write it from scratch every time.
Maybe we can add such a module to Qbs.
However, there are several questions on the implementation.
Right now, there's a PR for the installPaths module which specifies the default locations for common directories such as "bin", "lib", etc.
However, it is not enough to have one dir per binary since there's also a debugInfo, importLib on windows and possibly "exporter" files such as qbs module or pkgconfig file.
Here's the list of (possible) props per item

// Application
installDir : string
debugInformationInstallDir : string

install : bool ????
installDebugInformation : bool  ?

// Library
libraryType: string ("static"/"dynamic")

installDir : string
debugInformationInstallDir : string
importLibInstallDir : string 

install : bool ????
installDebugInformation : bool  ?
installImportLib : bool ?

createQbsFiles: bool (installQbsFiles? exportQbsFiles?)
createPkgConfigFiles: bool (same as above)
createCMakeFiles: bool (same as above)

// Plugin aka LoadableModule
installDir : string
debugInformationInstallDir : string

install : bool ????
installDebugInformation : bool  ?

One question mark means that we might want to have this prop in a module rather then leaving it only in item.
Four question marks mean that we should probably NOT include this prop in a module at all - bool install is a Product thing. OTOH one may want to choose whether to install static libs/import libs globally.

So the question is - do we extend the installPaths module with those additional props or we leave it as-is and create a new module that uses the installPaths module for defaults.

==one module==
Pros: a single point of entry, it is clear which prop controls what

==two modules==
Pros:
-clear separation between directory paths and item properties
-easier to re-use installPaths in other contexts, e.g. in custom items
Cons:

• extra indirection level - "Application.installPath" defaults to "itemconfig.applicationInstallDir" which defaults to "installPaths.bin"
• not clear when to override "installPaths.bin" and when itemconfig.applicationInstallDir. Can be solved by making installPaths "constant" or documenting properly .e.g. "always use itemconfig"

There's also a question whether we should have a separate module per item, e.g. "Application" item is configured by the "application" module
Pros:

• item scope is effectively the module name, saves some typing - e.g. application.installDir vs itemconfig.applicationInstallDir
• different modules can have pros with the same name (e.g. installDir, debugInformationInstallDir), otherwise props should be prefixed with the corresponding item
• this scales better with new items
  Cons
• cannot have shared props between items (e.g. itemconfig.installDebugInfo for all items).