Separates navigation from core, completes JSDoc comments and replacing `bind` with `$.proxy`

Separates the navigation aspects into several plugins. The first plugin `Navigation` encapsulates the pagination, including the absolute navigation (dots) and the relative navigation (next and previous). The
second plugin `Hash` encapsulates the URL hash navigation.

### Navigation Plugin

This refactors the implementation for the pagination. Instead of rebuilding the absolute navigation whenever the core refreshes, it just adds/removes the difference with one DOM manipulation. Thus it doesn't use data within the DOM elements anymore. Instead this is done by an internal array and the index is the position of the DOM elements.

This also should allow to generate a pagination like `(<) [dot] [dot] [dot] (>)` by using `navContainer` and `dotsContainer` targeting the same element.

### Refactoring of the Core

#### Pages

The core no longer knows anything about 'pages'. This is a concept encapsulated with the `Navigation` plugin. Thus the core is kept leaner. But this also introduced a new callback `onTrigger` for plugins. It
allows plugins to extend the event argument before its triggered. In this case to provide the page information with every event.

#### Public Events

This also refactors the core by removing the events `animateto`, `update` and `updated`. They are replaced by a more generic approach by extending the events `change` and `changed`, which represent the changing of an specific property within the core and this property is always included in the event arguments. This approach is very similar to `propertychange` events used in JavaScript, C# etc. The benefit of this approach is to keep the namespace of core events keep simple and clean instead of creating for each specific case a new event. It is also easyer to remember. The downside of this approach is that the numbers of event handlers for the events `change` and `changed` are higher.

Here is how the generic `change` and `changed` events work:

```Javascript
$('.owl-carousel').on('change.owl.carousel changed.owl.carousel', function(e) {
  // you can change object property values directly e.g.
  if (e.property.name == 'item' && e.property.value) {
    e.property.value.addClass('special');
  }
  // to change scalar property values or replace 
  // object value use the `event.data` e.g.
  if (e.property.name == 'position') {
    e.data = 0;
  }
});
```

#### Public Methods

Besides the events this refactors the public interface of the core by integrating the internal function `gotToLoop` into `goTo` an renaming `goTo` into `to`. Thus `to` operates depending on `options.loop` which simplifies the client code like `next` or `prev`.

### JSDoc

All JSDoc comments has been replaced by this pattern, which should be better readable and fixes also some issues with the `@param` tag (see http://usejsdoc.org/tags-description.html, http://usejsdoc.org/tags-param.html, http://usejsdoc.org/tags-todo.html, http://usejsdoc.org/tags-returns.html, http://usejsdoc.org/tags-access.html):

```Javascript
/**
 * Description for `foo`.
 * @public
 * @param {String} bar - Description for `bar`.
 * @param {Boolean} [foo=false] - Description for `foo`.
 * @returns {Boolean} - Description for the return value if any.
 */
Class.prototype.foo = function(bar, foo) {
  return true;
}

/**
 * Description for `bar`.
 * @protected
 * @todo There is always something to do.
 */
this.bar = {};
```