fix all those "Alias" issues

I noticed that the topic about alias routes wasn't completly fine yet.
I had a look at #692, #693 and #712 and also saw multiple threads at the board, complaining about a missing feature when it goes about replacing the tokens in the url:
https://groups.google.com/forum/#!searchin/f3-framework/alias/f3-framework/cctEWVHNBVo/3RD0XvaJG_kJ
https://groups.google.com/forum/#!searchin/f3-framework/alias/f3-framework/xUrMhuZlXDo/esHedT2tD6sJ
https://groups.google.com/forum/#!searchin/f3-framework/alias/f3-framework/uQhZZKoc-vI/7i6TNKJn-p8J

so here is a proposal.

1. keep the alias name of the current route in a hive var. (`ALIAS`)
2. use that current alias name, to fetch the route url from the `ALIASES` hive array
3. added a method to assemble the URL based on a given alias name.

here is how it looks now:

```php
$f3->route('GET @foo: /alias-test/@a/@b', function () {
	echo \Template::instance()->render('test.html');
});
```

```html
<a href="{{@ALIASES.foo}}">old way, still works. auto-populates @a and @b</a>
<a href="{{ \Base::instance()->alias('foo','@a=123,@b=germany') }}">
the long new method way, that let you change all tokens
</a>
<a href="{{ 'foo', '@a=456,@b=foo' | alias }}">convenience token filter method</a>
```

There would be other ways to solve it too, and maybe have it a bit nicer, like `@ALIASES.foo(@a=789)` but i don't wanted to create another plugin for that (with magic `__get` or `__call  methods)` and wanted it to be fully backward compatible. 

It would have been nice to have a move generic url parser like `{{@ALIASES.foo,'@a=456,@b=foo'|alias}}` but this doesn't work completely, because the main problem is that this line https://github.com/bcosca/fatfree/blob/dev/lib/base.php#L2227 is nice for having pre-filled alias routes, but also takes the chance of changing the tokens to something else afterwards, because they would already be replaced if your current route contains parameters that are also used in the alias route. It all would probably be nicer if it wouldn't do it here, but to keep compatibility, i did a workaround with a copy of `$this->hive['ALIASES']` that is still untouched, and backup the `PARAMS`, since the `parse` method would overwrite them and cause weird behaviours if your app continues after rendering some urls.

so what do you think? 

I would change Base::build() to take an optional $params parameters, rather than clobbering a hive var and then restoring it. It's cleaner.

Also one issue that may arise here is an error handler relying on the hive which has not been restored?