Refactor link handlers

The interface of link handlers and link handler factories is strange, hard to debug, and it's doing something extremely simple (checking if a URL matches and extracting stuff from it) in a highly overcomplicated way. It could be refactored like this in my opinion:

• have a base interface Link (the shorter the name the better, current names are huge)
• The interface has only a few extractor related methods, e.g. getExtractor() returns the extractor corresponding to the link.
• The interface also has a few app-facing public methods that are meant to be used only by the app (and not by other parts of the extractor). For example, a getUniqueId() method that returns a stable and unique ID for each resource, so it can be used as a primary key in NewPipe's database.
• Each extractor has a corresponding Link implementation. Every Link's constructor takes a URL and builds an instance of Link, but throws an exception if the URL does not match the expected link format.
• Each Link implementor may also have other constructors, e.g. YoutubeSearchLink would have a constructor that takes the query and any search filters.

Start by locating the existing link handlers and link handler factories, then map how URLs are matched, extracted, and consumed by the application. Compare that structure with the proposed Link interface and constructors. Done would mean a consistent Link implementation for each extractor, stable app-facing identifiers, and equivalent URL and search behavior.