allow tracking.tracker => tracking#tracker

Both on Maira's talk at FrontinBH - great presentation btw - and at the documentation examples I saw this kind of example:

``` js
var myTracker = new tracking.MyTracker();

myTracker.on('track', function(event) {
// Results are inside the event
});

tracking.track('#myVideo', myTracker);
```

After talking with @eduardolundgren, I got that it might be important to keep `tracking.track( 'id', );`, this is even good for API backwards compatibility.

I wonder if it's possible to extend `tracking` prototype with a `track` method to call `tracking.track` giving the instanced obj, like this (following the last examples):

``` js
myTracker.track('#myVideo');
```

I believe it could be crude done this way:

``` js
tracking.prototype.track = function( elem ) {
tracking.track.call( elem, this );
};
```

The benefits would be directly related to a simple usage, it looks redundant calling tracking again.

Through by this issue's perspective, it would even be better to have `tracking` to `Tracking` to encourage its use only as a obj class/constructor. I need to go deep on the code to even allow my perception and build a better judgement.

Start by reading the implementation and current usage of tracking.track, the tracking constructor/prototype, and the documentation examples shown in the issue. Decide whether an instance-level track method should complement the existing API; done means the proposed usage works without breaking tracking.track('id', instance) compatibility.

Written by the indexing model from the issue text.