Rename CreateParams to WebViewCreateParams

This is to support CreateParams for objects other than WebViews (for future
enhancement).
Major refactor of the Toolkit public interface

Previously, Toolkit was a bloated struct with a bunch of static functions that
were used for a couple of things:

* configuring different aspects of the toolkit (for example, setting thread
  mode and registering plugins).
* performing operations on the toolkit (for example, creating WebViews and
  Profiles).

This commit splits these two concerns into separate classes:

* ToolkitCreateParams, ToolkitFactory: used for configuring the toolkit, and
                                       instantiating it.  This will be used
                                       once at startup.
* Toolkit: this is now a pure interface that is implemented by ToolkitImpl, and
           provides methods to create WebViews etc.

This ensures that applications provide all the configuration parameters upfront
when creating the Toolkit, which will simplify the implementation a little bit.

One of the motivations for this change is to make it easier in the future to
have different implementations of Toolkit.  Another benefit is that this will
allow us to cleanup Statics, because a lot of stuff in Statics right now exists
purely as a temporary storage place for toolkit configuration parameters.
Statics cleanup: move Profile management to ProfileManager

This commit moves all the Profile management out of Statics and into a new
class called ProfileManager.  An instance of ProfileManager is owned by
ToolkitImpl.
Statics cleanup: move renderer info to RendererInfoMap

This commit moves the management of per-renderer info out of Statics into a new
class called RendererInfoMap.  An instance of RendererInfoMap is owned by
ToolkitImpl.
Statics cleanup: move plugin info and dictionary path to ToolkitImpl
Implement WebView::mainFrame() in WebViewProxy only

The mainFrame() method can only ever be used for in-process WebViews and only
when using the RENDERER_MAIN thread mode.  Therefore, the only way an
application can use it is if it has a WebViewProxy.
Add "misspelled word" to context menu params
Automatically perform spellcheck on load

Previously, spellcheck would only happen while typing or moving selection away
from a word.  With this commit, we will perform spellcheck whenever a document
is loaded, if spellcheck is enabled on the profile.  Also, turning on
spellcheck will request spellcheck across the entire document.

In order to implement the document-wide spellcheck, we added a new method to
WebElement called "requestSpellCheck()".  This method will traverse the
children and request spellcheck whenever it comes across editable content.
Request spellcheck when custom words dictionary changes

When the custom words dictionary changes, we will visit all RenderViews and
request a document-wide spellcheck.

Also, enhance the SpellCheckMsg_ResetCustomDictionary message to contain the
new list of custom words, so that we don't need to send two messages.
Add spellcheck menu to blpwtk2_shell

The new menus allow users to enable/disable spellcheck and autocorrect, and
also select the languages that will be used.  Also, an "Add to dictionary" item
is added to the context menu if the user right-clicks on a misspelled word.