Re-implementation of chooser dialog with Vaadin 8 powered UI framework. New strategy for resolving the definition. Current strategy is rather rigid:

• choosers are bound to apps => there cannot be a chooser without an app. Also one app can hardly have two choosers.
• chooser UI auto resolution logic works but maybe could be improved (the first encountered browser sub-app picked and chooser definition is derived from it)

possible solution:
Maybe rather associate choose dialogs with the caller sites (mostly - LinkFields). Let the link field describe chooser in its definition. If it would require "whatever is brought by 'that' app" - the current logic would still be sufficient.

However, the link field could point to a content type, maybe JCR workspace, or smth completely custom. That way every link field would be able to have their own unique chooser, but then the burden of creating it will be put on e.g. LinkFieldFactory and not on the respective app.

The latter probably not bad, cause it would potentially let us get rid of that hack that starts the app instances without showing their UI (see AppController#startAppWithoutFocusing or similar). Instead of that hack, a dedicated chooser dialog factory (or similar utility) should setup IoC context, find out where the choose dialog definition should come from and then instantiate it.

Improvements, can be split into a separate enhancement story:

• Limit link field to a certain node type.
• Ability to have multiple different chooser dialogs for the same app (workspace).
• Multiselect in a chooser dialog.
• Improve the APIs. Restrictive chooser callback today.