Parent the AppInfoDialog using a ModalDialogHost

Parent the AppInfoDialog using a ModalDialogHost

On Mac (both with and without MacViews) web_contents()->
GetTopLevelNativeWindow() can return NULL. So it is not valid for (e.g.)
extension_settings_handler.cc use this as a parent window for the
AppInfoDialog.

Also, in general, parenting off a gfx::NativeWindow is bad, since the
lifetime is hard to control.

This CL introduces  
- CreateModalDialogViews(views::DialogDelegate*, web_modal::ModalDialogHost*)
which will eventually replace  
- CreateBrowserModalDialogViews(views::DialogDelegate*, gfx::NativeView);

BUG=

[tapted, 2014-11-13 07:26:25]

(not for review)

Hi Andre - this is what I was thinking for the app list dialog

but it's currently blocked on making `web_modal` a proper shared component.
(this actually shouldn't be too hard..)

An alternative might be to make the AppListViewDelegate in chrome/browser/ui the
ModalDialogHost, and "pretend" to the ModalDialogHostObserver that it's getting
destroyed whenever the profile changes.

https://codereview.chromium.org/719203003/diff/1/ui/app_list/app_list.gyp
File ui/app_list/app_list.gyp (right):

https://codereview.chromium.org/719203003/diff/1/ui/app_list/app_list.gyp#new...
ui/app_list/app_list.gyp:190: '../../components/components.gyp:web_modal',
unfortunately `web_modal` isn't a proper component -- it's just a static
library. So this is currently blocked on making it a shared library, with
WEB_MODAL_EXPORT and all that jazz.

[Andre, 2014-11-13 21:53:36]

On 2014/11/13 07:26:25, tapted wrote:
> (not for review)
> 
> Hi Andre - this is what I was thinking for the app list dialog
> 
> but it's currently blocked on making `web_modal` a proper shared component.
> (this actually shouldn't be too hard..)
> 
> An alternative might be to make the AppListViewDelegate in chrome/browser/ui
the
> ModalDialogHost, and "pretend" to the ModalDialogHostObserver that it's
getting
> destroyed whenever the profile changes.
> 
> https://codereview.chromium.org/719203003/diff/1/ui/app_list/app_list.gyp
> File ui/app_list/app_list.gyp (right):
> 
>
https://codereview.chromium.org/719203003/diff/1/ui/app_list/app_list.gyp#new...
> ui/app_list/app_list.gyp:190: '../../components/components.gyp:web_modal',
> unfortunately `web_modal` isn't a proper component -- it's just a static
> library. So this is currently blocked on making it a shared library, with
> WEB_MODAL_EXPORT and all that jazz.

Looks good!

[Andre, 2014-11-18 23:42:58]

On 2014/11/13 07:26:25, tapted wrote:
> (not for review)
> 
> Hi Andre - this is what I was thinking for the app list dialog
> 
> but it's currently blocked on making `web_modal` a proper shared component.
> (this actually shouldn't be too hard..)
> 
> An alternative might be to make the AppListViewDelegate in chrome/browser/ui
the
> ModalDialogHost, and "pretend" to the ModalDialogHostObserver that it's
getting
> destroyed whenever the profile changes.
> 
> https://codereview.chromium.org/719203003/diff/1/ui/app_list/app_list.gyp
> File ui/app_list/app_list.gyp (right):
> 
>
https://codereview.chromium.org/719203003/diff/1/ui/app_list/app_list.gyp#new...
> ui/app_list/app_list.gyp:190: '../../components/components.gyp:web_modal',
> unfortunately `web_modal` isn't a proper component -- it's just a static
> library. So this is currently blocked on making it a shared library, with
> WEB_MODAL_EXPORT and all that jazz.

Thinking about this some more.
I actually like the idea of making AppListViewDelegate the ModalDialogHost.
It minimizes app_list's dependency, and I'm not sure something like
AppListContentsView
should know anything about modal dialogs.