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 understand your point of view. Let me just add an argument (I am not opposed to your decision at all, just discussing a little :smile:). You say: 

> 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.

In all cases, you have to: Either update the visitors or update the model. And from my point of view, this is cleaner to write and easier to read separated codes that make something different (in this case, serializing in a different format). Moreover, if we can do that in the model directly, we can do that in a visitor in the same way. Same API is exposed, same data are exposed also.

This is an implementation detail and it would require some refactoring. I understand and assume this is not a priority. I will continue as it is :wink:.