Remove the $youtube service; allow for multiple on one page

Ok, this is related to #3 and of course is a substantial "breaks everything" type of change!

I can understand if you want to reject it on that solely based on principle, but here's a bit of what I did:

I did remove the `$youtube` service. I didn't think it was needed. This does mean you don't get those utility functions in your main script and you could bring that back, but I beefed up the directive to handle all the same things, so I argue it's not really needed (but it does change how you interact with it a bit).

So first off, each instance of the directive keeps track of its own player, and this is even attached to the scope if you want to use it in a controller (but it won't be immediately available when the controller is executed. This is weird, but I think acceptable (see some examples below)).

Because of this, you can have multiple independent directives on the page and they play nicely together.

Let's start with this HTML:

```html
<youtube-video video-id="'E_yan51myNI'"></youtube-video>
<youtube-video video-url="'https://www.youtube.com/watch?v=cq3NYObTthM#t=30'" player-id="banana" player="myPlayer"></youtube-video>
<div>
    Video 2 length: {{ myPlayer.getDuration() }}

    <button ng-click="jump()">Jump!</button>
</div>
```

and this JavaScript (from a controller):

```javascript
$scope.$on('youtube.player.ready', function (event, player) {
    if (player.id === 'banana') player.playVideo();
});

$scope.$on('youtube.player.paused', function (event, player) {
    console.log('paused', player.id);
});

$scope.jump = function () {
    $scope.myPlayer.seekTo(140, true);
};
```

When the page fully loads, you'll get 2 videos, and the second one, since it has a `playerId` of `banana`, it will begin to play (trigger in the controller) starting at 30 seconds (because of the `#t=30` in the URL).

If you start and then pause the first video, it will have a unique directive-generated ID, since the element itself doesn't have an ID. You can leave an ID off for convenience (i.e. if you just have one video on the page and don't really need it), but obviously if you wanted to actually reference it, you'd be wise to put a `player-id` attribute on the element. It will also fallback to a regular `id` for legacy reasons, but I figured it didn't hurt to be verbose.

You'll also note that there is a button that you can click and it will jump the 2nd video to 140 seconds. This is because I gave it a `player` attribute, so I can access the player and manipulate it directly. This wouldn't be available right away, but would be available by the time most users clicked on the **Jump!** button (you could hide until it was ready if you really wanted to).

Lastly, you'll notice in the event callbacks, it passes in the player, so you can further manipulate the player in the callbacks because the player that trigger the event is passed in (it's 3am, so excuse my circular talk).

One other minor change I made was to make it `$emit` events up from the directives scope (rather than `$broadcast` down from the `$rootScope`). This should make it so that if you have directives in sibling scopes (i.e. two sibling controllers on one page), each other's events won't bleed into each other (untested).

Rather, everything is untested. I do plan on adding some tests... maybe... eventually. But I want to see if you are event interested in the PR or direction at all before I did anything else.

Even if you reject it, we'll probably use this fork in our current project (multiple videos is a must for us). I did think your project had some good stuff in it, and it was worthwhile to refactor your project rather than start from scratch. So thanks for that! =)
i think we should go back to the `$watch` that was here before. i think it was a bit clearer having the `ready` than the `needsDelay` and `playerCallbacks`.

also, with this code, if you don't have a `videoUrl` when the directive gets instantiated, it will start `$watch`ing `videoId` instead. so if your controller doesn't have the `videoUrl` when it gets instantiated, but then it receives one later (maybe after some async request), it wouldn't display the video.

the old `$watch` ensured that you had either `videoUrl` or `videoId` before it began `$watch`ing.