Add support for arbitrary calendar headers

[nickgartmann]

In order to get a calendar invite sent via email to show RSVP buttons, the ics file must contain a METHOD header which matches the method provided in the Content-Type header of its file attachment (See the first paragraph of the iMIP RFC: https://datatracker.ietf.org/doc/html/rfc6047#section-2.4)

This can be achieved by inserting the headers manually after the ics has been generated, but this PR adds support for arbitrary headers to be added below the PRODID header.

[lpil]

Hello! The code looks good, thank you for the contribution. Some questions:

Is the headers key the design used in other ics libraries?

What would happen if the header key END or similar was used? It seems that many header values could produce invalid ics.

Would you mind updating the changelog?

[nickgartmann]

After some research of other libs, it looks like they call them properties but also there is a finite list of properties that are supported (per: https://datatracker.ietf.org/doc/html/rfc5545#section-3.7). They are:

• CALSCALE
• METHOD
• PRODID
• VERSION

You have everything but METHOD already in there, so maybe instead of adding headers I should just add method as an optional param in to_ics/1? I could also add the option to set CALSCALE and VERSION manually

[lpil]

That could work, though is it clear? What does the Ruby library do there?

[nickgartmann]

They define the settable properties manually and then loop through all of the calendar properties when serializing

They call the property ip_method - they had it as method but changed it in 2014 - I suspect this change was driven to minimize confusion with ruby meta programming naming conventions. Ruby prefers the name method over functions since you can't have a standalone function not attached to an object. The reasoning here is a guess though because the commit messages don't talk about the change at all and there was not a PR that drove the change.