There's quite a lot here - because caldav support needed some fair
refactoring/etc. to get working. Happily after this I can commit a
little more incrementally as I'll be able to deploy what I have here...

...due to needing a password, I don't have any caldav test data- the
format for making a dav subscription is something like so:

INSERT INTO dav_connections ("id", "url", "username", "password") VALUES ('00069420-74d2-4ba8-85d6-4fc679810c02', <base URI>, <username>, <password>);
INSERT INTO subscriptions ("id", "reference", "dav_connection") VALUES ('12a89516-65f7-4874-8449-671b7c8444af', '/my/href/of/my/calendar/', '00069420-74d2-4ba8-85d6-4fc679810c02');

It's worth noting that - I believe - we return some minorly noncompliant
data for colors (i.e. I think the list of values that are supported for
calendar colors is greater than the list of values supported for, say,
event colors). Happily, I guess, after I wrote the caldav colors feature
I found out that Google Calendar doesn't support ical colors anyway. I
also then didn't write the feature for direct ical subscriptions so...
...another time, maybe.

A key function of calpoll is taking multiple .ics calendars and merging
them together. This adds basic ical merging as follows:

- "Calendars" are in a database
- Calendars have multiple "subscriptions" (ical subscription URLs)
- When getting events from a calendar, we fetch all subscriptions, parse
them and add everything to one big ical file
- We expose this over http so this can itself be used as an ical
subscription URL

The reason we do it like this rather than, say, having an endpoint to
/merge/ calendars and be done with it is we want this to be an
application which you can share URLs out of even if you don't want to
make the subscription URLs of each underlying calendar public (e.g.
Google Calendar private .ics subscription links). We would also like the
ability to add support for more calendar sources in the future -
particularly, say, I need support for WebDav calendars for Stalwart.

---

You can test this change by using the merge-holidays-moon-phases.sql
queries in test-data/ to set up a test calendar like so:

$ cat test-data/merge-holidays-moon-phases.sql | psql $DATABASE_URL
$ curl http://127.0.0.1:3000/calendar/32da8949-b21c-469d-a2bc-f5763af186c6
BEGIN:VCALENDAR
VERSION:2.0
PRODID:ICALENDAR-RS
CALSCALE:GREGORIAN
BEGIN:VEVENT
CLASS:PUBLIC
CREATED:20240522T091304Z
DESCRIPTION:Public holiday
[...]

$ curl http://127.0.0.1:3000/calendar/00069420-74d2-4ba8-85d6-4fc679810c02
BEGIN:VCALENDAR
VERSION:2.0
PRODID:ICALENDAR-RS
CALSCALE:GREGORIAN
END:VCALENDAR

$ curl http://127.0.0.1:3000/calendar/non-uuid
Invalid URL: Cannot parse `id` with value `non-uuid`: UUID parsing
failed: invalid character: expected an optional prefix of `urn:uuid:`
followed by [0-9a-fA-F-], found `n` at 1

---

For these tests to work, you'll need to have $DATABASE_URL set to your
database, and you'll have to be running the code. The easiest way to do
that is with devenv and the nilla shell provided here...

$ devenv up
[...wait for TUI showing postgres running...]

[...in a separate terminal...]
$ nilla shell
nilla$ sqlx database reset
nilla$ cat test-data/merge-holidays-moon-phases.sql | psql $DATABASE_URL
nilla$ cargo leptos watch

It'd be nice to integrate this with nilla (especially so as not to have
to maintain double the lockfiles/etc.) but for now I guess this is OK...