Implement content_shell app on top of chromium-efl library.

Implement content_shell app on top of chromium-efl library.

This is an uglier, but faster solution to get content_shell
running on top of EFL chromium port. Instead of splitting
EFL port into content-EFL/EWK implementation parts it
it creates an efl specific content_shell_efl target that
depends on both original content_shell_lib and chromium-efl.
In essence it builds content_shell on top of both EFL content
API port and EWK specific content implementations.

Although the solution abuses chromium module boundaries and
introduces a lot of potentially invalid objects into
content_shell app it allows content_shell to work
with current M34 code base without refactoring it. The main
goal is to get something working fast without breaking
chromim-efl.

Long term, the EFL specific implementations of internal content
interfaces (RenderWidgetHostView, WebContentsView) should be
separated from EWK specific parts, moved into content module or
it's dependencies and original content_shell app should be used.
As it is right now the EWK specific objects like EWebView or
EWebContext will be invalid in cases where the content API is
initialized by content_shell app.

Added M40 Fixes

Original patch: http://165.213.202.130:8080/#/c/68602/
Original author: Piotr Tworek <p.tworek@samsung.com>

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

Change-Id: Ifc8c3ba660245d8637a49643239f111ecd3f0480
Signed-off-by: Kamil Klimek <k.klimek@partner.samsung.com>