Related collections: Performance vs. supporting non-HAL formats

Some related collections are expensive to compute, in the sense that they require additional database queries. Examples include `Period#getContentNodes()` and `Day#getScheduleEntries()`.

With our current implementation, we try to support not only the HAL JSON format, but also JSON+LD and GraphQL. For HAL, we sometimes add an annotation `#[RelatedCollectionLink]`, and the API response therefore only contains a filtered link like `/content_nodes?period=/periods/1a2b3c4d`, so all the contentNode data which is fetched from the database is completely ignored afterwards. So if we were only supporting HAL JSON, there would be no need to perform these additional database queries. But omitting the queries would break the JSON+LD format and possibly also GraphQL (not sure about that one).
This affects all API calls where a period or day entity is normalized (e.g. when loading or patching a single period, when loading all periods, when loading a camp with embedded periods, etc.)

This issue was originally raised by @usu in https://github.com/ecamp/ecamp3/pull/2700#discussion_r867438094 and the decision might influence how to proceed in a past discussion in https://github.com/ecamp/ecamp3/pull/2683#discussion_r873156500.

We should decide how we want to proceed with such getters on our entities. Probably we should assess the performance impact of these first.