Refactor the `calendar.search()` a bit

[tobixen]

calendar.search() takes lots and lots of parameters - and there are some recursive calls to the search method - it seems that sometimes parameters are dropped, and in any case it's very ugly to include the full list all the time.

To support advanced queries from buggy servers, it's also needed to do client-side filtering (#434 for instance). At some point in the future I would also like to support other protocols than CalDAV, the native search support may vary dependent on the protocol.

I think the best pattern here is to organize all the search parameters into some few classes and reduce the number of parameters with a lot.

The search parameters are currently:

Filters:

• xml - for power users, actual xml to be sent to the CalDAV server. Using this will cause all other search parameters to be ignored. It will also not work with client-side filtering or other interfaces than CalDAV.
• comp_class - overlapping with the bools todo, event and journal.
• In addition there are some internal filters ignore_completed1, ignore_completed2 and ignore_completed3.
• include_completed - special, if set to False and todo=True, this will filter out completed tasks.
• start, end - for date-searches
• uid,summary,comment,class_,class,category,description,location,status,due,dtstamp,dtstart,dtend,duration,priority. For advanced searches (not supported by CalDAV) it should be possible to filter not only by the equality operator (==), but also <>, <, >, >=, <=.

Sorting:

• sort_keys - list of what keys to sort by
• sort_reverse - should the sorting be reversed? (this doesn't seem very feature-complete, it should be possible to reverse sort on some keys and not all)

Output:

• props - ask the server for extra properties. Apparently useful for ... getting sync tokens?
• expand - should recurring components be returned with the "master" data, or should recurrences be returned?
• server_expand - as above, but ask the server to do the work
• split_expanded - if set to True, return one object for each recurrence. If set to False, recurrences are bundled together into one recurrence object, in accordance with RFC4791

PROPOSAL:

• Create three new classes, ComponentSearchFilter, ComponentSearchSorter and ComponentSearchController. Use dataclass.
• Let search accept three new parameters which should be instances of the above classes
• We should still take either a long list of parameters as before (backward compatibility + ease of use) and construct the three objects internally.

[tobixen]

Quite some work done in pull request #563 - I need to do some functional testing towards various caldav servers before I can feel confident that the refactoring is a noop.