spec'd in HTML5. In particular:

1) [i]frames are always KHTMLParts, that are consistently navigated.
Based on previous commits, they can handle other mimetypes
via wrapping in img/embed/pre as appropriate

2) The initial document for the iframe is created synchronously.

3) Better handling for frame names, including dealing with renaming and the
like.

This fixes #191667 (which expects a document for plaintext), #159028
(ad script on cbc.ca redirecting to blank page, synchronous initial iframe creation),
#235652 similar on target.com, and most likely #193362
(some ad scripts on arstechnica.com; however I can't seem to hit them so I can't
confirm)

Techinically, I did:
- rename the high level requestObject overload (and requestFrame) to
loadObjectElement/loadFrameElement to make their difference from the
lower-level requestObject clear --- the two overloads were different
enough to be a readability issue
- factor out a whole bunch of code from processObjectRequest so we
can use it for creating the initial KHTMLPart for [i]frames
(some of the refactoring also fixes javascript: source frames)
- loadFrameElement now responsible for initial KHTMLPart creation using above
- processObjectRequest always uses the pre-created KHTMLPart and navigates
it for [i]frames; though it may still ask to save stuff and the like.
- comment a whole bunch of stuff
- iframe element does initial creation when inserted into document,
cleanup when removed. 

BUG:191667
BUG:159028
BUG:235652
CCBUG:193362

svn path=/trunk/KDE/kdelibs/; revision=1140104