Routing: Implementing JComponentRouterAdvanced

This PR implements a new base class for component routers, which can be used to create rules based routers that are dynamically extendable.

### The idea
Components that stick to the Joomla MVC style should be able to create a fully working router with as little work as possible. At the same time, component routers should only handle views, since those are the only ones that you should be able to link to. If you have something that is not a view, it should execute and then redirect to a view again. This means that we only have to create SEF URLs for views. Views are pretty well defined, too.

### How it works
A router extends from this class and in its constructor, it registers all its views with a bunch of its data and the hierarchy between them. The idea is, that views form a tree hierarchy, where traversing along the tree towards the leafs gets you higher and higher in the hierarchy. In case of com_content, the articles and its article view would represent the leafs of the tree, the categories with their category view represent the nodes of the tree and the categories view, which displays all categories, would represent the root of the tree.
So we already have a kind of hierarchy in our views and we register them accordingly in our router. We start with the categories view. That has no id, has no parent view and is not nestable. Then we have the category view, which has the ID "id" in the query, has the categories view as a parent view and that view is nestable. This means that while traversing along the above described tree, we can have a node that is a category view and its child-nodes are also category views.
Based on this, we can then find the right Itemid for example (by starting from the node given by our query, for example the article view and its ID and traversing along the tree to its root, all the while comparing the menu items that we have with the current node that we are in) and/or add the category hierarchy from that menu item to the URL and last but not least add the article slug to it.
Since we are not registering "we have categories and content items" but a flexible hierarchy, you could in theory go as far as having categories that contain tags which again contain content items and those contain something else again. So the hierarchy is not limited to the category/content-item system that we have in Joomla right now, but allows for a lot more.

A specific example could look like this:
```php
	public function __construct()
	{
		$this->register('categories', 'categories');
		$this->register('category', 'category', 'id', 'categories', '', true, array('default', 'blog'));
		$this->register('article', 'article', 'id', 'category', 'catid');
		$this->register('archive', 'archive');
		$this->register('featured', 'featured');

		/** Insert adding rules to process the URLs here **/
	}
```

### The rules
Based on the hierarchy that you have to define above, we can then write rules that process the input query to transform it to the SEF URL that we want. I will soon provide a PR with a rule that will always find the right Itemid that can be used with all components out there that implement this router. This means, that we don't need a component specific code for this in the ContentHelperRoute classes or like it is currently proposed by me in #5285, #5294 and #5295.
Similarly the current routers behavior can be combined into a generalized rule that works of of the hierarchy that was described above. That means, that we can summarize all the code in our core routers in those rules and instead of having 11 component routers, we would only have one rule that implements this specific logic.
I have to admit, those rules get pretty complex and difficult to maintain, but it would mean that no component developer needs to write his own router anymore, but can use the core rules instead.

### The component router
A specific component router could simply consist of the code that I posted above. Adding a plugin event to it and some further logic, and we would specifically only have this:
```php
/**
 * Content Router
 */
class ContentRouter extends JComponentRouterAdvanced
{
	function __construct()
	{
		$this->register('categories', 'categories');
		$this->register('category', 'category', 'id', 'categories', '', true, array('default', 'blog'));
		$this->register('article', 'article', 'id', 'category', 'catid');
		$this->register('archive', 'archive');
		$this->register('featured', 'featured');
		parent::__construct();
	}
}
```
This would be all that is needed for our core routers. There are however some things that I would propose for the future and that would allow to make the system more robust and a bit more flexible.
In order for the system to be able to retrieve the right data, I think it would be good to introduce router specific getters for things like the article ID/slug. So a com_content router would have a method getArticle() that either returns the ID of the article that the slug and the category ID belongs to or that returns the ID with the slug attached, based on the input. I'm not sure about the correct interface here yet. The getCategory() method is a generalized version for all category related views. The system that I have in mind expects an interface like that from JCategoryNode for all nestable views. Since I don't like the JCategoryNode implementation very much anymore, since its too category specific, I started a discussion on a node interface in #5227. Feel free to join in there for this part.

### getPath()
The getPath() method in this class returns a path of views from the node/leaf that is given by the query to the root of the tree-hierarchy. This allows us to simply check if each entry for example corresponds to a menu item and thus set the right Itemid or to add a segment to our url from that matching menu-path item to our original node/leaf defined by the query. It's a helper method that I think a lot of rules will make use of.

### Current issues
The main issue right now is, that I did not get around to writing unittests for this code yet. I will provide those as soon as possible, but I doubt that this will be before christmas.

Since there is no code yet to test this with, I'd like to ask for a code-review by the maintainers and merging this based on that code review.

This was made possible through the generous donation of the people mentioned in the following link via an Indiegogo campaign: http://joomlager.de/crowdfunding/5-contributors
@Hackwar I agree with Ercan. 

Having 6 parameters in a function is a bit of a code smell. Ideally functions have 2 max 3 arguments. If more arguments are needed a better approach would be to use a object to express the various arguments as Ercan suggests. This also makes the API cleaner and more declarative.

Give it some more thought :)