Reactive pos-container-contents

[jg10-mastodon-social]

Implements and closes #190

Builds on #186

• Add LDPContainer.observeContains as reactive equivalent to LDPContainer.contains
• pos-container-contents updates its contents by observing LDPContainer.observeContains
• Tests have been written
  • all new code is covered by unit tests
  • the happy path of a new feature is covered by an end-to-end test
    • Will be covered by Upload file to container on mobile #188 - there is currently no way for the user to trigger an update in the PodOS browser.
  • manual explorative tests have been performed
• all dependencies are updated to the latest patch version at minimum
• the CI pipeline passes
• documentation is up-to-date
  • TSDoc style comments on important functions, properties and events
  • N/A stories for new PodOS elements have been added to storybook
    • makes existing element reactive
  • N/A Readme.md files of PodOS elements have been re-generated
    • No change
  • N/A architectural decisions are documented as an ADR
  • Changelogs are updated according to Keep a Changelog

[angelo-v]

question: Why graph and not subject?

[angelo-v]

thought: i wonder if the merge, pipe, filter pattern should be a convenience function on store. I guess we will need it a lot

[jg10-mastodon-social]

The graph limits changes to this container, i.e. ldp:contains triples in other documents won't trigger. In principle this minimises some triple injection issues, though in practice I was simply trying to find an efficient filter.
I'll add a test for it.

[jg10-mastodon-social]

I'm still expecting that we might want to reuse specific filters - at the moment a new observable is created for every call.
I don't want to prematurely optimise for that though - I think we can refactor with some performance oriented tests later.
If we end up doing that, it'll be more than just a convenience function.