Extension points for custom controls and interactions

This PR makes a number of changes that relate to developing custom controls and interactions in applications.

**For interactions:**

The `handleMapBrowserEvent` method is now `handleEvent`. And it can now be specified by a application-specific interaction using the `handleEvent` constructor option.

For example

```js
app.MyInteraction = function() {
  ol.interaction.Interaction.call(this, {
    handleEvent: app.MyInteraction.prototype.handleEvent
  });
};
ol.inherits(app.MyInteraction, ol.interaction.Interaction);

app.MyInteraction.prototype.handleEvent = function(e) {
  // …
};

var myInteraction = new app.MyInteraction();
```

Another option is to instantiate the base class directly:

```js
var myInteraction = new  ol.interaction.Interaction({
  handleEvent: function(e) {
    // …
  }
});
```

**For controls:**

The `handleMapPostrender` function is now `render`, and a `render` option is added to `olx.control.ControlOptions`.

So this is how you can specify a `render` function in a custom control:

```js
app.MyControl = function() {
  ol.control.Control.call(this, {
    render: app.MyControl.prototype.render
  });
};
ol.inherits(app.MyControl, ol.control.Control);

app.MyControl.prototype.render = function(e) {
  // …
};

var myControl = new app.MyControl();
```

or:

```js
var myControl = new ol.control.Control({
  render: function(e) {
    // …
  }
});
```

I initially planned to do the same for `setMap` (i.e. add a `setMap` option making it possible to override `setMap` as set in the prototype), but I've decided to leave this for another time. The reason is https://github.com/openlayers/ol3/pull/2841, which I closed a few days ago, but which may make sense to merge eventually. With #2841 custom controls would listen to `change:map`  to know when `setMap` is called.

Please review.


That would also work. Your approach feels more like extending the class, whereas my suggestion makes it feel more like configuring a render function. I lean more towards my suggestion, because we said we don't want the library to feel like users can extend whatever method they want.