v0.11.0 - client side expansion and more

Warning

v0.10 and v0.11 does introduce some "bugfixes" and refactorings which
are supposed to be harmless and which haven't caused any breakages in
tests - but I cannot vouch for that it will not have unintended side
effects in your environment. If you're using the caldav library for
production-critical tasks, you may want to hang on for a while before
upgrading, or wait for v0.11.1. Version 0.11 contains minor changes
that may break backward compatibility (according to the SemVer
specification backward incompatible changes are allowed when doing
0.x-releases. Anyway, according to my knowledge this is the first
time a release contained things breaking backward-compatibility. The
return from the search method has changed a bit, I think I can do this
because v0.10 hasn't been out for long, hence most likely most users
will be using calendar.date_search() rather than calendar.search()
for doing timerange searches, and because the change is relatively
harmless and unlikely to break things. The return from the data
property is now enforced to be a normal string with unix linebreaks,
this is more likely to cause problems, but the previous behaviour was
unpredictable and would anyway sooner or later cause problems for
people depending on the return type to be a binary or being with
carriage returns).

Summary

• Daniele Ricci has made support for client-side expanding, intended
  for the calendar servers that supports recurrences but not
  server-side expanding.

• For expanded recurrences, the search-method will (by default)
  deliver each recurrence as a separate object (i.e. caldav.Event).
  This is slightly backward incompatible with v0.10.

• Now obj.data will always return an ordinary string with ordinary
  line breaks, while obj.wire_data will always return a byte string
  with CRLN line endings. This may break thinsg if the client
  expects a binary return, or depends on carriage returns in the
  output. While the return type of obj.data has been slightly
  unpredictable, it may still have been deterministic dependent on
  usage pattern - so the caller may have gotten some expectations
  which may now be broken.

• Bugfixes, some of the new code in v0.10 didn't handle icalendar data
  containing a timezone. Some other minor bugfixes.