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`

I'm not sure I agree. I think this is a bit of an odd case because the `Tags` instance is a way of simultaneously configuring two extensions, one for the viewer and one for the editor. (As such, perhaps the names could be different, `t = new Tags(); t.EditorExtension; t.ViewerExtension`...?)

But the key difference between this and the API (or lack of API) that you've proposed is that it inverts control. It gives the widgets control over where in their lifecycle extensions (which are just functions that accept a widget argument) are called.

For example, it's possible we could reimplement the `Markdown` plugin as a function that changes the default filter of the Viewer. I think

```
var v = new Annotator.UI.Viewer({
    extensions: [Annotator.UI.Markdown, MyOtherExtension]
});
```

reads better than

```
var v = new Annotator.UI.Viewer();
Annotator.UI.Markdown(v);
MyCustomExtension(v);
```

Yes, it makes the mechanism more opaque, but I'm not sure that's a bad thing in this case. Widget extensions are meant to be usable by people who don't understand how they're implemented.