Reconsider where the URL interceptor gets called and what version of a URL is stored

Currently,  we intercept url properties as soon as the property is set, but only if it is a simple QUrl. If it is a JavaScript expression, it does not get intercepted.

In QML 3, we probably only want to intercept urls  at the place where they are actually used. This would mean that any redirection is applied after any interception, and only the original URL is stored and used for further URL resolution. This is different to what e.g. HTML does.

QTBUG-61209 and https://codereview.qt-project.org/214106 show that we have a more complicated problem there: Redirected URLs cannot be intercepted and vice versa. Right now, we circumvent the problem by using the original, non-redirected, URL for resolving further URLs in case of a redirection. This is different from how e.g. HTML handles URLs, and rather unintuitive.

There is a solution: We could restrict interception to local URLs and redirection to remote ones. Furthermore we could prohibit local URLs to be made remote by interception.

URL interception right now is only possible by using private API and our own interception only concerns QQmlFileSelector, which only handles local URLs anyway. However, the relevant headers, qqmlabstracturlinterceptor.h and qqmlengine.h, are in fact public. Only the setUrlInterceptor() and urlInterceptor() methods are marked internal by qdoc comments. Therefore you won't get the familiar private API warning when using them.

Such a change would reduce the (rather ugly) code in that area, and result in cleaner rules on what works and what doesn't. On the flip side there are probably users of this API who don't realize that it's private and whose code will break this way.