Factor out custom property mapping/serializing/deserializing logic from `CustomPropertiesBackend` to make it reusable

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.

Sometimes, a piece of code needs to access a custom property of a calendar. Currently, this is only possible when this piece of code has access to a SabreDAV Server instance. We should allow Nextcloud code to short-circuit this and access the properties directly.

Reimplementing the mapping and deserialization logic leads to duplicated and unmaintainable code.

Example: #51081

Describe the solution you'd like
It would be nice to move the property mapping and fetching logic to another class which doesn't depend on a Server instance. This could be the PropertiyMapper for example.

Describe alternatives you've considered
None

Additional context
None

Locate CustomPropertiesBackend and review how it currently maps, fetches, serializes, and deserializes calendar custom properties through the SabreDAV Server instance. Compare the duplication described in example #51081 and assess the proposed PropertiyMapper direction. Done means the logic is reusable without a Server instance and existing behavior remains covered by the relevant tests.