Create custom HTML5 video player for IPFS files

In the web UI, if you navigate to a file's contents, currently the UI relies on the user's browser to render the contents. That works well for images and PDFS, and for audio and video files, most browsers now have some sort of player for those files. But especially for large video files, the user experience can be lacking, as the browser will attempt to fetch the video pieces in playback order, and expect them to be streamed from the IPFS node in that order. But if it's a file that the IPFS node doesn't have locally, and it needs to request the files from its peers, different peers may respond with different chunks of the video in different order. Relying on the browser's default player may block playback or saturate socket connections (e.g. https://github.com/ipfs/go-ipfs/issues/5740), making playback slower.

To make the best user experience for playing videos hosted on IPFS, using modern web APIs (Media Source Extensions (MSE)), a better player could be implemented, to be used in the default IPFS web UI, and made available for other sites to use/embed IPFS video content in their site, to make the user experience better when working with this sort of playback.

### Proposal
A large file hosted on IPFS is loaded in a similar manner as a Torrent file is: it's split into chunks/blocks, and different peers may respond to give different chunks from different locations in the final file. Most torrent software give some sort of a UI element that visualizes what pieces of the raw data have been transferred:


And some may give the option to prioritize blocks in the beginning of the file (if it's a video, to enable starting playing the beginning, while it's downloading). That sort of an indicator I think is key to helping users understand what's happening with their video playback.

The UI elements of a video player of a have evolved to have some common elements that users now expect. For example, in the YouTube player:


The current playback head is at 5:41 (visualized by a solid color bar), the amount of video that's currently loaded is shown as a faded out bar (to the right of the playhead), and in this screenshot, the user is mousing over a point in the future of the video (8:05; visualized by an even more faded out bar). Because the point the user is hovering over is past the "already loaded" point of the video, the user knows that if they click there, the video will need to buffer for a bit to queue up the next bit of the video to play.

Taking the idea of a torrent file progress bar, I propose a UI like this:


The situation is the same: the playback head is at 5:41, and the user is mousing over 8:05. In this UI, the "what parts of the video are loaded" is moved to a secondary track above the playhead, with loaded-and-ready sections colored in a different color from the playback track. With this visualization, the user can see that if they click there at 8:05, the player will need to buffer for a while (since that section is not loaded yet), but if they skipped forward a little further, there's content that's loaded a little ways forward that they could jump to.

Having a more rich front end widget for video playback would then allow for additional (optional) enhancements where the front end could make calls to the IPFS node to adjust block priorities based on user interaction ("content at the 8:05 mark and forward from there just got bumped up in priority, guys!"), rather than just passively waiting for the IPFS node to finish loading the content.

### Rationale
Sites like [BitTube](https://bit.tube) and [D.tube](https://d.tube) have started to spring up, aiming to make a rich video browsing experience, and both have created custom player implementations to try and load IPFS videos in the most effective way for users. Setting up a standard UI and toolset for application developers to utilize could streamline that process, and increase adoption of IPFS in general. It could also help with debugging as it would bring to the forefront more information about what is happening to the video, instead of leaving a user stuck at a loading animation (and possibly navigating away out of frustration).