Rename ProfileImpl to ProfileProxy

Previously, ProfileImpl was our only implementation of Profile, and it just
posted the config structures to the browser-main thread.  We would do this even
in the 'ORIGINAL' thread-mode.

In this commit, we renamed ProfileImpl to ProfileProxy (following the same
naming scheme used for WebViewProxy), and changed BrowserContextImpl to also
implement the Profile interface.

So in the 'RENDERER_MAIN' thread-mode, we will create a ProfileProxy that posts
the config structures to the BrowserContextImpl in the browser-main thread.
But in the 'ORIGINAL' thread-mode, we will just create a BrowserContextImpl and
return that to the application.

Also, ProfileManager has been replaced with BrowserContextImplManager.  We no
longer need to keep ProfileProxy objects alive until threads stop, so they now
just get deleted when they are no longer referenced.  The BrowserContext
lifetime is a bit more complex though, because they are still being referenced
by some objects (for example, the in-process renderer host), even after the
application destroys the Profile.  The BrowserContextImplManager will be used
temporarily to keep the BrowserContextImpl objects alive until the browser-main
thread has finished pumping messages.  Once we cleanup all the post-'destroy()'
references to BrowserContext, we can get rid of BrowserContextImplManager and
let the BrowserContextImpl objects get deleted inside destroy().
Add ProcessHost and ProcessClient

This is in preparation for supporting blpwtk2 clients in multiple processes.  A
ProcessHost will be created in the browser-main thread, for each blpwtk2 client
process.  This creates a new IPC channel that will be used to communicate with
a ProcessClient, which will be created in the application-main thread in each
blpwtk2 client process.  Note that right now, the ProcessHost and ProcessClient
interfaces are identical, but they will diverge over time.

When using the 'RENDERER_MAIN' thread mode, we will create 'in-process'
ProcessHost and ProcessClient objects.  In subsequent commits, we will change
ProfileProxy and WebViewProxy to use the IPC channels provided by ProcessHost
and ProcessClient, instead of directly posting tasks between threads.

Once the ProfileProxy and WebViewProxy conversion is complete, we can start
creating 'out-of-process' ProcessHost and ProcessClient objects, which will
finally allow blpwtk2 clients to live in multiple processes.
Make ProfileProxy use IPC instead of PostTask

This is a largely mechanical change, replacing the PostTasks in ProfileProxy
with IPC messages.  Profiles are created and destroyed using control messages,
handled by ProcessHost.  The ProcessHost creates a ProfileHost for each
ProfileProxy.

Note that right now, profile creation/destruction control messages are
synchronous.  This is only a temporary situation, and is necessary to ensure
that the BrowserContextImpl has been created before the WebViewProxy tries to
access it.  Once WebViewProxy has been converted to use IPC as well, then we
can change this to be asynchronous, and ProfileProxy will no longer need to
hold references to the BrowserContextImpl.

Also, in order to simplify the IPC param traits for ProxyConfig, we have
exposed references to the internal data members in some 'net' classes.

Also note that ProfileProxy no longer needs to be reference counted, since it
is no longer used in multiple threads.  ProfileProxy::destroy() will
immediately delete the object.
Make FindOnPage::Request a separate struct so it can be sent through IPC

This is a slight refactoring of FindOnPage::Request, which is used when
WebView::find() is called.  This commit makes it a simple struct, to simplify
the IPC implementation of WebView::find().  We also replace the usage of
'blpwtk2::String' with 'std::string'.

Also, the executeOn implementation has been moved to WebViewImpl.  This will
make it possible in the future to create a light-weight blpwtk2 dll for clients
that do not need in-process renderers.
Make Impl structs for ContextMenuItem and ContextMenuParams

This is a pimpl-ification of these two publicly exposed classes.  The Impl
structs use std::string and std::vector types, which makes them easy to use in
IPC param traits.  Also, the set* methods are no longer exposed, since these
are only ever used within blpwtk2.

This commit requires a change in the public interface because the methods that
previously returned 'blpwtk2::String' must now return 'blpwtk2::StringRef'
instead.
Remove WebViewDelegate::handleMediaRequest

This be being removed because:

* our WebRTC integration is no longer working (changes in upstream/latest since
  this feature was implemented have introduced new requirements).
* none of our apps are actually using this right now.
* it poses complications for the conversion to use IPC instead of PostTask.

WebRTC support can be added again later when necessary.  But for now, we will
remove it to simplify the IPC conversion.
Make WebViewProxy use IPC instead of PostTask

Like the IPC conversion for ProfileProxy, this is a largely mechanical change,
replacing the PostTasks in WebViewProxy with IPC messages.  WebViews are
created and destroyed using control messages, handled by ProcessHost.  The
ProcessHost creates a WebViewHost for each WebViewProxy.

Also like ProfileProxy, WebViewProxy no longer needs to be reference counted,
since it is no longer used in multiple threads.  However, we need to make it
support WeakPtr, because there is still a PostTask (to the current thread) in
'WebViewProxy::onAboutToNavigateRenderView'.
Move rendererAffinity -> hostAffinity conversion to BrowserMainRunner

This is just a refactoring of existing code to prevent it from being duplicated
in ProcessHostImpl and ToolkitImpl.  Creation of the InProcessRendererHost is
now handled entirely within BrowserMainRunner.
Use async messages for creating/destroying profiles

Now that WebViewProxy has been converted to use IPC, it no longer needs to
obtain the BrowserContextImpl from ProfileProxy, so we can make ProfileProxy
use async messages to create/destroy profiles.  ProfileProxy no longer needs to
hold a reference to BrowserContextImpl.
Add final sync control message before shutting down threads

This is necessary to ensure that all IPC messages have been handled by the
ProcessHost before shutting down the channel.  Otherwise, things like
BrowserContextImpl and WebViewImpl may not get destroyed properly.