Calculating VAVAILABILITY

[evert]

This PR is a work in progress to add VAVAILABILITY calculations to sabre/vobject.

VAVAILABILITY is currently largely useful in when generating freebusy reports, so this is also where this needs to be fixed. It makes the calculations a lot more complex, so it's also requiring some refactoring in the freebusy generator.

Todo:

• Reintegrate the new FreeBusyData object back into FreeBusyGenerator. It's kind of nice separate, as it is, but I'm afraid there's little use for it outside of freebusy calculations. By merging it back into the class we keep a cleaner namespace.
• Do the actual VAVAILABILITY expansion.

Benchmark

Old:

__global__  |||||||||||||||||||||||||||||||||||||||||||||||||||| 15891ms, 100.0%
parse       |                                                      358ms,   2.3%
fb          |||||||||||||||||||||||||||||||||||||||||||||||||||  15533ms,  97.7%

peak memory usage: 14M
current memory usage: 12M

New:

__global__  |||||||||||||||||||||||||||||||||||||||||||||||||||| 22741ms, 100.0%
parse       |                                                      308ms,   1.4%
fb          |||||||||||||||||||||||||||||||||||||||||||||||||||  22433ms,  98.6%

peak memory usage: 14M

Unfortunately it seems that the new system is quite a bit slower. We'll have to figure out how important it is to fix this, and if there's some easy wins to be made.

[evert]

Not gonna bother with making it faster. It's much better this way and we already got major speedups in the 4.x branch, I think it's within acceptable limits.

I'm also not reintegrating FreeBusyData into FreeBusyGenerator. It's a bit unfortunate to have a separate class, but it does make things a lot more clear.

So when I fixed the broken tests, this is ready for merging.