Comment 1 for bug 1196002

Recommended reading: https://wiki.gnome.org/Vala/Gedit3PluginSample
I just realized a ton of problems we're facing would be solved by moving to libPeas and it's actually not painful because we're not forced to port everything at once. So it's not a goodie, but we can avoid re-inventing a number of wheels here.

Benefits:
  Support external extensions
  Separate interfaces for Midori.View/ Browser/ App/ Completion/ SpeedDial
    - The core would provide entry points; extensions no longer need to manually connect to all signals and manage lifetime of objects, a huge source for bugs at the moment
    - The same interfaces can be used internally to make
    - Support external/ third-party extensions first class, with a libmidori etc.
    - Allow other languages to be used, such as Javascript and Python
    - Based on the previous two assumptions, a website for extensions à la Firefox would become feasible
    - include WebKit2 WebExtension support in the new API

Concerns:
    - extension_init can remain the existing entry point; the new API would use peas_register_types (see example above)
    - we have no final concept for WebKit2 yet - this is a good chance to introduce it