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 thought about this more... the #1 main problem I have with passing arrays and other values, is that it means there's another intermediate format that needs to be documented.

Yes, it's not 100% consistent when you compare it to json, but json is a very different beast. In a way, what getJsonValue produces is almost immediately also the end-result of the function. It's such a 1:1 direct representation that it does make the most sense to me.

For XML, I think this is the most logical way to do this, and it also gives the most flexibility. Now we can simply defer to the documentation of `Sabre\Xml\Reader + Writer` instead of explaining that the array in `setXmlValue` is similar to what would be returned from Reader::getInnerTree() or what would be accepted by Write::write().

I would agree that it's a bit less straightforward for newcomers to get into, but I suspect that the average end-user never needs to touch this anyway. It's a concern for maintainers, and for those this should still be simple enough.