Fix multi_string_property: None when absent, snapshot lists (refids, REQUEST-STATUS) — part of #1722 - #1765

Linked issue

• Contributes to [Bug] Inconsistent behavior of list properties #1722

Description

This is the first PR in a planned series fixing the inconsistent
list-mutation behavior described in #1722. Full root-cause discussion
and the remaining checklist are in the issue thread.

Fixes multi_string_property (used by refids and REQUEST-STATUS):

• fget returns None when the property is absent (previously [])
• fget always returns a disconnected copy — mutating the returned
  list no longer affects the component. Previously this only worked
  when a single value was stored; with 2+ values, the getter returned
  a live reference into the component's internal storage, so
  .append() on the returned list silently mutated the component.
• fset normalizes storage to always be list-shaped internally, even
  for a single value, closing off the root cause (Component.add()
  stores a bare scalar on first add, only becoming a list on the
  second add)
• List elements are now consistently returned as plain str (not a
  mix of str/vText depending on how they were added)
• Setting None or [] now deletes the property

Remaining work, tracked as follow-up PRs against #1722: RESOURCES
property (see also #1696), categories, attendees, rrules,
related_to, links, concepts, and CATEGORIES multi-group/LANGUAGE
support.

Checklist

• I added a change log entry, following the instructions in all subsections under Change log requirements.
• I followed icalendar's Artificial intelligence policy and disclosed my Responsible AI use in my commit messages, if applicable.
• I added or updated tests, if applicable.
• I ran and ensured all tests pass locally by following Run tests.
• I added or edited documentation as necessary, both as docstrings to be rendered in the API documentation and narrative documentation, following the Style guide.

Additional information

See #1696 (open, adds RESOURCES via the same multi_string_property)
— that PR will inherit this fix regardless of merge order.