Implement xCal support

Useful links:
  * [RFC6321](https://tools.ietf.org/html/rfc6321), xCal: The XML Format for iCalendar.

To-do:
  * [x] require sabre/xml,
    * [x] update `composer.json`,
    * [x] sabre/xml requires PHP5.4, hence update sabre/vobject (done by Composer?),
      * [x] if requires PHP5.4, we can use the [`JsonSerializable`](http://php.net/jsonserializable) everywhere (all top-classes having a `jsonSerialize` method),
      * [x] update code accordingly (e.g. short array syntax),
      * [ ] update documentation accordingly,
  * [x] create the helper in `Sabre\VObject\Reader`,
  * [x] add XML serializer helpers everywhere (e.g. in children of `Sabre\VObject\Node`),
  * [ ] timezones used by xCal and xCard are differents, must check the compatibility,
  * [x] create the reader (parser):
    * [x] support properties:
        * [x] support all names,
        * [x] support all values (types of values):
          * [x] `binary`,
          * [x] `boolean`,
          * [x] `cal-address`,
          * [x] `date`,
          * [x] `date-time`,
          * [x] `duration`,
          * [x] `float`,
          * [x] `integer`,
          * [x] `period`,
            * [x] `start`,
            * [x] `duration`,
            * [x] `end`,
          * [x] `recur`,
            * [x] `until`,
            * [x] `count`,
            * [x] `interval`,
            * [x] `bysecond`,
            * [x] `byminute`,
            * [x] `byhour`,
            * [x] `byday`,
            * [x] `bymonthday`,
            * [x] `byday`,
            * [x] `byyearday`,
            * [x] `byweekno`,
            * [x] `bymonth`,
            * [x] `bysetpos`,
            * [x] `wkst`,
            * [x] `freq`,
          * [x] `text`,
          * [x] `time`,
          * [x] `uri`,
          * [x] `utc-offset`,
        * [x] support special cases:
          * [x] `categories`,
          * [x] `resources`,
          * [x] `freebusy`,
          * [x] `exdate`,
          * [x] `rdate`,
          * [x] `geo`,
            * [x] `latitude`,
            * [x] `longitude`,
          * [x] `request-status`,
            * [x] `code`,
            * [x] `description`,
        * [x] support all parameters:
          * [x] support the specific `value` iCalendar parameter,
    * [x] support all components:
      * [x] `vevent`,
      * [x] `vtodo`,
      * [x] `vjournal`,
      * [x] `vfreebusy`,
      * [x] `vtimezone`,
      * [x] `standard`,
      * [x] `daylight`,
      * [x] `valarm`,
    * [x] support XML extensions.

Code review:
  * usage of iterators has been heighten (see https://github.com/fruux/sabre-vobject/pull/161),
  * clean code (https://github.com/fruux/sabre-vobject/pull/162),
  * better performance when possible (see https://github.com/fruux/sabre-vobject/pull/162).


Left apart for now:
  * [x] [RFC6321, section 3.1. Pre-Processing](https://tools.ietf.org/html/rfc6321#section-3.1),
  * [ ] `LIBXML_*` options when reading or writing.

To fix:
  * [ ] `rdate`.
I think there is something to be set for making a distinction between:

1. The object model
2. A system that serializes the object model into a different format

For one, if you want additional formats in the future, it means you can create clean, independent system that don't affect *1*.

So lets take xml as an example. If the system that generates the xml is completely independent from the object model (document, component, property, parameter) then there's an assumption that the xml generator can be implemented in this model, without really touching the document model.

This can only be true, if the 'xml writing system' is completely aware of _every_ value type (e.g.: all the derivatives of `Sabre\VObject\Property`).

This also implies that when a new type is introduced (for example, `VAVAILABLITY` is added, and there's work on [new calendar scales](tools.ietf.org/html/draft-ietf-calext-rscale-02)), you will need to go back to all the serializers and also make them aware of this change.

So for this reason I don't think a true independence of writer and the properties themselves can exist. Either the writer will need to have per-property rules on how to serialize the values, or the properties themselves need to be responsible for serializing.
 
So I'm sorry, but I would prefer this feature to be done by making the `Component`, `Property` and `Parameter` classes implement `Sabre\Xml\XmlSerializable`.