Rework Tags plugin

This PR reworks the Tags plugin and introduces the Widget extensions concept.
- Widget extensions are functions that can be added to a widget as options.extensions (expects a list)
- These functions are run on the widget at rendering.
- This is a hook point to customize widgets, add necessarily new fields, etc.

The Tags plugin:
- Converted from coffee to js.
- It is no longer a plugin but an UI extension, so moved from plugins directory, to ui directory
- The filtering part is gone, since we have a separate plugin for that
- Offers two widget extensions: `configureViewer` and `configureEditor`

Okay, just looked into this. The inheritance pattern is fine, we just have a couple of assumptions that we been make:

1) That when `installExtensions` is called we have a fully constructed object to make available to the callee.
2) That `Widget.call(this)` should be called first thing in the constructor so that our subclass has all methods available to them.

Unfortunately these two things are directly opposed, and really as far as I can see is caused by the requirement to call render in the constructor (which doesn't even render). I think we should separate the construction of the object from the attachment to the document.

My suggestion would be to rename render to `.attachTo(element)` and call this in the DefaultUI module, then in this method call `maybeInstallExtensions()` (or similar) which will ensure that extensions are installed the first time attachTo is run but not again.