platform specific imports and import security

[Marco Martin]

Good news everyone! http://www.youtube.com/watch?v=1D1cap6yETA

I am playing with the new api QQmlAbstractUrlInterceptor
(to completely work will need https://codereview.qt-project.org/#change,65626
and https://codereview.qt-project.org/#change,61208)

the thing will permit to do a kind of mod_rewrite for qml.
every file or remote url that will be asked by qml (even a component 
declaration such as Foo{}) can be filtered with this.
so what can be done with this:

* security *
** forbid access to absolute paths that are ouside both the applet package and 
the import paths (implemented)

** forbid or allow remote urls with some mechanism (todo)

** black or whitelist for imports (todo)

** since some applets and applications will have to do imports pretty much 
just for them, if all those "private" imports have some recognizable pattern, 
applets can refuse to import any private import that is not their "own" (this 
is more a social contract rather than security)


* platform specific content *

** for all files in the package, all urls are rewritten by resolving them with 
package.filePath, with all the file resolution magic given by PLASMA_PLATFORM 
env var.
This was very limited in plasma1, now every single file is resolved in this 
way and is enforced (yep, no way to have an image outside images/ or a js file 
outside scripts/, existing applets seem to still work)

** for files in imports
It's trying as well the same trick for imports, so the touch components may be 
loaded when needed.
it has a pro and a con.
pro: not necessary anymore to install a whole import: we used to have most of 
the qml files installed two times in order to have a whole "desktop set" and a 
whole "touch set" now only modified files need to be installed.

con: a QQmlAbstractUrlInterceptor needs to be installed in order to work, so 
works only for plasmoids at the moment (while we would want it to work on any 
qml app)


A way to solve the con may be installing the QQmlAbstractUrlInterceptor in 
kdeclarative (therefore for plasmoids we would need to install a subclass of 
the kdeclarative one that knows also about plasma packages)

Provided the bug of https://codereview.qt-project.org/#change,61208 gets fixed 
soon, the whole mechanism seems to work really well.
The only thing i'm a bit concerned of (but hopefully shouldn't incide too 
much) is potential overhead mostly at startup, since it adds a *lot* of string 
comparisons (and possibly some filesystem lookup as well)

Cheers,
Marco Martin