New feature: Added parameters to skin include directive ($PARAM[Name])

Skin includes have been enhanced to accept parameters and thus be able to generate dynamic content based on them. Basically, they can now act as "procedures" where needed. This can help clean up XMLs a bit, making skins much easier to read and maintain. It also allows for more component-based modular skin design.

The syntax is as follows:

_include definition_:

```xml
<!-- default parameter values are specified here -->
<include name="MyControl1" param:posx="120" param:posy="120" param:border="5" param:background="foo.png">
  <control ...>
    <posx>$PARAM[posx]</posx>
    <posy>$PARAM[posy]</posy>
    <control ...>
      ...
      <texture border="$PARAM[border]">$PARAM[background]</texture>
    </control>
    ...
    <!-- nested include call -->
    <include param:color="$PARAM[color]">MyControl2</include>
    ...
  </control>
  ...
</include>
```

_include "call"_:

```xml
  <include file="MyControls.xml" param:posx="225" param:posy="150" param:color="white">MyControl1</include>
```

Rules:

* Attributes with namespace prefix "param:" in include tag denote custom parameters, to make them distinguishable from built-in ones ('file', 'name', 'condition', etc.)
* Default values for parameters can be specified within *include definition* tag
* Concrete arguments are specified within *include call* tag
* Actual arguments are a combination of these two, with passed arguments having a higher priority over default ones
* Parameter references in the form of $PARAM[ParamName] are replaced with actual arguments within include definition body (inside tag values and attribute values)
* There can be one or more parameter references specified within a single tag/attribute value, possibly in combination with other characters
* Parameter references are resolved before everything else ($INFO labels, $LOCALIZE, etc.), so these can be passed as arguments too
* Parameter references that refer to missing/undefined parameters are replaced with empty strings
* Extra parameters in include call that are passed but not referenced anywhere within include definition are ignored
* Incomplete parameter references (without closing ']') are logged as errors and left as is, rather than resolved to empty strings

This feature was proposed and discussed in more detail here: http://forum.xbmc.org/showthread.php?tid=190135. It requires a change in Wiki documentation which I can help with if it gets accepted.
is there a reason why we use boost::function instead of std::function?