Do not queue up ViewMsg_UpdateWebPreferences messages before RenderView gets created.

Do not queue up ViewMsg_UpdateWebPreferences messages before RenderView gets created.

In EWebView::UpdateWebKitPreferences there is some logic to
avoid losing IPC messages. Logic is "if RenderView is not created
yet, do not send an IPC message to it".
However this logic does not apply to ViewMsg_UpdateWebPreferences
any more.

For instance, if one calls EWebView::UpdateWebKitPreferences
before RenderView is created, this is what would happen:

1) RenderViewHost::UpdateWebkitPreferences is called and "store"
the WebPreference instance passed as parameter.
2) Since RenderView is not created yet, ViewMsg_UpdateWebPreferences
would be queued up to be sent delayed.

In RenderViewHostImpl, though, as part of the RenderView creation,
the web_preference instance that was "store" is passed. So, there is
not need to send a delayed message.

As the code is today, after RenderView creation, EWebView::RenderViewCreated
(the hook) is called, and the message queued in (2) is sent again.
Although it might sound warmless, real problem is that the delayed
message has different values than the last message "stored" in
RenderViewHost. This leads to bugs.

Bug: http://107.108.218.239/bugzilla/show_bug.cgi?id=14441

Reviewed by: a.renevier, j.majnert, sns.park

Change-Id: I870d5028e96e5b3bcc3c5f13325e8f1983296888
Signed-off-by: Antonio Gomes <a1.gomes@samsung.com>