Introduce a basic URL router system

[bbecquet]

Description

After trying to simplify the "URL shards" system, I'm introducing a real router as a better way to manage navigation between the app states and interaction with the browser history.

This is a really simple, ad-hoc implementation, very easy to remove or replace if we decide to use something more elaborate in the future (src/proxies/app_router.js).

In this new architecture, the root component (src/panel/app_panel.js) defines URL templates with optional parameters, corresponding to valid app states, and for each template a rendering function. The panels are now only switched on or off through this function. Re-renders are the result of new URL states and not the contrary.
Transition between valid states is made explicit through a single dedicated function (navigateTo), so it happens reliably at a single place.

Why

• the "URL shards" system was far too complicated and required logic parts scattered everywhere in the code.
• proper browser history management was near impossible with the shards, as history pushes happened in the panel functions doing the actual renderings. Restoring past state through browser back/forward buttons resulted in new pushes. With the new system this is seamless.
• valid app states and corresponding URLs are now explicit and grouped in a single place, making them easier to manage.
• first step towards a single rendering flow system, which would be a better app architecture IMO.

[GuillaumeGomez]

A magical value. :)

[amatissart]

Looks good to me.
I have just a few questions about URL parsing.

[GuillaumeGomez]

Code looks good to me. Still need to check it locally though.