Variables in svg attributes

This PR allows skin developers to add variables in svg attributes.

Even if it's not finished, I wanted to show this work to get feedback before continuing.

For the moment, three use cases are available : 
```xml
<tagname attr-name="value1 value3 var(varname)"/>
```
With it, "var(varname)" will be replace by the value of varname if it exists. If not, it will be replaced by an empty string (keep the vars at the end).

```xml
<tagname attr-name="prop1:val1; prop2:value2; var( prop3, varname );"/>
```
In this case, "var( prop3, varname );" will be replaced by "prop3:varvalue;" or removed if the variable doesn't exist in the skin context (variables have to be at the end of the attribute).

```xml
<tagname attr-name="default-value" var-attr-name="varname"/>
```

This syntax will trigger an overwriting of attr-name attribute by the value of varname if it exists.

The rules I followed to do it :
+ I chose a syntax looking like the "url()" css rules.
+ These syntaxes keep the svg file readable by a classical svg renderer (your web browser for example) but they have to be at the end of the attribute to do that.

I have adapted the skin I'm working on (https://github.com/demos/developer_skins/tree/master/Advanced-Player) to use variables in attributes and it allowed me to make it really simpler. Furthermore, this skin is now fully designed with svg so it should work perfectly on a retina screen.

The remaining questions : 
+ Find a clever syntax for paths <path d="M 5.5 0.5 l -5 0 l 0 28 l 5 0" />. Expressions look like good way to deal with it : <path d="M 5.5 0.5 L -5 0 L 0 28 L 5 0" var-d="M expr( 0.5 + height ) 0.5 L expr( -1 * height ) L 0 var(width) L height 0"/>
+ Support for encapsulated vars and expressions and chose a syntax: expr( 5 + var(height) ) or expr( 5 + height ).
+ I've temporary added a skincontext on the state elements of WPushButton to be able to change the colors or text of buttons depending on their state. Other usefull cases will probably appear in the future.
+ Globally, invent a coherent and user friendly syntax.

Thanks in advance.  


I think it looks a bit better to parse here a pointer. Remember that you store it as pointer later anyway.