Improve handling of the Qt runtime when it is pre-deployed to a device or included in the app package

When a user likes to use and install an own version of Qt for an app in development, the current approach is too cumbersome due to the following:

• the BAR descriptor file contains variables which are evaluated inside of Qt Creator only making this BAR descriptor file not usable for command line tools

• The default entry "<asset path="%QT_INSTALL_LIBS%">lib</asset>" used for Qt deployment leads to a totally over-sized app package because the "blackberry-deploy" tool treats symbolic links in the "lib" folder as real files and includes multiple instances of the same library under different version names

• There is no support for the possibility to pre-deploy Qt and use it as a shared asset by pointing to it as run-time from multiple apps in development

The following suggestions for the new flow in the management of Qt used for deployment target to address these issues. Ideally, this should become a feature in 3.1.

When a user starts a new project or adds a BB10 kit to an existing project, it has to define how to handle Qt (notice, no "5" here). The choices are:

1. "Add Qt from the selected Kit to the application package each time it is created. Note: this option provides most flexibility, but increases the size of the package"
2. "Deploy Qt from the selected Kit to the device for shared use by all apps in development. Note: This step is done once for each device you use for development. It provides smallest packages, but makes your app relying on Qt being available in XYZ folder on the device it run on"
3. "Use Qt pre-installed in the device firmware". At this point we should think of some auto-detection mechanism which would allow the user to find out a) if a compatible version of Qt is installed in the firmware and b) if such version has already been pre-deployed at the choice #2

Those options should be added in "Run" settings to better fit with the current general Qt Creator approaches.

Today, most people would choose option 2 for development with Qt5 as long as Qt5 is not available in all in-market devices. Unfortunately, 2nd option does not work if you package a final version of the app into a signed bar file. Due to this, we should let the use to decide if Qt should be included in the signed bar file or not with the following options:

1. "Package Qt from the selected Kit and add it to the app assets. Note: this increases the package size"
2. "Keep the app using Qt which installed in the device firmware. Note: this should be your preferable option if you are certain that a compatible version of Qt is available in the minimal platform version you specified as compatible in the BAR descriptor file"

An introduction of the above options leads to the fact that according entries will be hidden from the view on the BAR descriptor file and will be added on the fly on top of those edited by the user. So no manual tweaking of those entries in the BAR descriptor file is possible anymore or will be just overwritten. User should use Qt artifacts provided via Kits. BTW, IMHO, no temp BAR descriptor file is needed for this, since we can post additional entires as options in the "blackberry-nativepackager" tool.

The only critical catch here are the env vars "QML_IMPORT_PATH", "QT_PLUGIN_PATH" and "LD_LIBRARY_PATH", since they can be used by the user to point to its own, additional installs, e.g. when the app includes other libs or its parts are made as plugins. Due to this the paths in those vars have to extended and not just blindly overwritten.