Add basic controls to the player

[christriants]

This PR adds basic players controls, which addresses issue #7.

We're adding a play button, volume button and track selector, replacing the controls that had been sitting below player. Each control is now its own component, and we attempted to move some logic relevant to these new components out of watch.tsx and to the respective component files.

To test these changes:

• The play button should resume audio (we will add play/pause functionality when feature: play/pause and running promise modified #9 is merged)
• The volume button should handle toggling mute
• The track selector button should open a menu with available tracks, and selecting a track should update the current video track

Additionally, I renamed usePlayer to player in watch.tsx. I think this is a positive change because:

1. it's idiomatic to name signals after the value they represent (player, setPlayer)
2. ‘use’ is commonly associated with React hooks
3. it reads as a direct reference to the player

All feedback is welcome!

[englishm]

It's really nice to see some UI elements here! Thanks!
I'm afraid I set up a merge conflict for you when I merged the play/pause PR. Sorry!

You may also be interested in some of the discussion on #4, in particular regarding what Web Components might allow us to do for the UI.

I would like to the move in the Web Component direction in the long run, but since that requires some refactoring work first, I'm happy to accept PRs that add UI elements like you have here in the meantime. Hopefully some parts of that work can be ported (or re-used in) to a media-chrome model.

[christriants]

@englishm No problem at all! Conflicts are resolved, and play/pause functionality has been added to the play button, since the PR to add that functionality has been merged.

Thanks for sharing that discussion. I will keep this direction in mind as this project continues (and hopefully contribute, as well)!

Appreciate you taking a look at this one.

[englishm]

Tested, works!

One minor issue I notice is that sometimes there seems to be a brief delay in responding to clicks, but I think that may be unrelated to these changes and it isn't a major issue so I'm not going to worry about it right now. (I wonder if it might be related to how we're waiting on keyframes?)

Thanks for this, @christriants! I'll merge and then we can start looking at @JoaquinBCh's refactor and switch to rollup, etc. 😁