Clarify auto-generated properties for `new` class methods

[stevepiercy]

This is a good issue for new-to-icalendar contributors. Help is welcome!

In #1459, we realized that the initial choice of wording in the docstrings for the new() class methods might not be accurate in regards to whether properties are required, optional, or recommended, per the RFC specification of these terms.

To work on this issue, select one class, then:

• Compare the usage of its current docstring grammar against their Python implementation and their RFC specification, and determine the next step.
• Either add a comment to this issue stating that you have verified that the docstring is correct as is, or create a pull request where you adjust the class's docstring to align with both the Python implementation and RFC.
• For a pull request, follow our contributor guide and its relevant sections.

Files to check

• src/icalendar/cal/alarm.py
• src/icalendar/cal/availability.py
• src/icalendar/cal/available.py
• src/icalendar/cal/event.py
• src/icalendar/cal/free_busy.py
• src/icalendar/cal/journal.py
• src/icalendar/cal/todo.py

Originally posted by @scop in #1459 (comment)

[andycheng2018]

Hi! I'm a student looking to make my first contribution. I'd like to take src/icalendar/cal/free_busy.py: its new() docstring says "Create a new alarm...", which looks like it should reference FreeBusy. I'll fix that and check the property wording against RFC 5545.

[w3lld1]

I’ll check src/icalendar/cal/journal.py. The current Journal.new() docstring documents an end parameter that is not present in the method signature; I’ll keep the change focused on that API-doc mismatch and validate the documentation build.