Added RFC7986 properties to calendar component

[espen]

No description provided.

[rahearn]

Thanks for the PR, @espen. In addition to the changes that I mention in-line, I'd really like us to support the recommendations in section 3 about outputting the VALUE attribute to maintain backwards-compatibility. A test or two demonstrating compliance would be very much appreciated as well.

[rahearn]

Several of these properties can actually be defined more than once, so they should use the optional_property method instead of optional_single_property On the calendar component, they are name, description, categories, and image

Suggested change

	optional_single_property :ip_name
	optional_property :ip_name

[rahearn]

The conference property was not added to the Calendar component, but should instead be added to the Event and Todo components (where they should use the optional_property method). Several of the other properties should also be added to additional components in addition to the Calendar.

[rahearn]

To be more clear, the tests I am interested in are around compliance with section 3. I don't think we need them for just adding the new properties.

Also, if you think that part is too large for you to be able to get to, or over your head, just let me know and I can take a look at either offering suggestions or take over implementing it.

[estani]

This wouldn't have caused any troubles, it's a pity it wasn't merged.
Perhaps a more general approach would be to allow for a hash whose keys will go thorough .to_s.upcase (afaict ical attributes must be uppercase always) and it's values gone through .to_s

much like:

cal.event.other_attributes = { color: '#FFFFFF'}
# ... when writing other attributes
other_attributes_str = other_attributes.map { |k, v| "#{k.to_s.upcase}:#{v}"}.join("\n")

same for parsing, everything that is unknown could end up in that hash.

This will make the library more robust to changes.
My 2c.