Merge tests setup and parametrization

[niccokunzmann]

I would like to following setup to merge calendars:

• tests/calendars has a lot of calendars that can be merged
• calendars that have a + in the file name combine two or more calendars
  e.g. one_event+x_wr_timezone.ics will contain the calendar that we expect as an output of the default merge process of the command line.

Tests will include:

• merging calendars in arbitrary order will result in the same calendar
  Parametrize this with NxN (all calendars merged with each other)
  This makes sure that we catch edge cases
• merging a calendar with itself once results in the same calendar merged with itself and again (with and without +)
• merged calendars merged with themselves result in the same calendar (with +)
• merging the inputs of a merged calendar together results in the merged calendar (with +)
  • parts should be merged in arbitrary order and result in the same calendar
• for all inputs of a merged calendar: merging the input into the calendar and vice versa results in the merged calendar
• Those merge processes are parametrized: Call via CLI, via merge function and via actually running a program on the command line with I/O
• make sure that most tests make a side-effect test: The original calendars' ics should stay the same after merge. The resulting subcomponents are copied. See also feat: merge RFC 7986 COLOR property for calendar components #321 (comment)

See also

• [Bug] Components not necessarily equal collective/icalendar#1224
• ae2cdeb#diff-cc1c7a7143e6ad6da6b7f83c04648f74dc4eb2efb03b724b97901e53863f97c1L25 - as an example that will be run on all files