Migrate module documentation to eclipse-score/baselibs

[4og]

After the docs-as-code is functional in the baseslibs repo, the whole content of https://github.com/eclipse-score/score/tree/main/docs/modules/baselibs should be migrated to the baseslibs repo.

The approach for the cross-repo traceability in docs: https://eclipse-score.github.io/score/main/design_decisions/DR-004-infra.html

Idea how to avoid need id conflict between score and baselibs repo during migration:

• PR1: There is PR in score repo removing baselibs module docs.
• PR2: baselibs depends on score module in bazel with a git_override pointing to that PR.
• Merge PR2.
• At this point, the PR1. cannot be merged yet due to references to baselibs elements. Example: https://github.com/eclipse-score/score/blob/main/docs/features/communication/docs/architecture/index.rst?plain=1#L52
• How to merge PR1? Options:
  • Introduce a cyclic dependency (maybe) in score repo???
  • Clean up feature architecture of most of features that it doesn't reference the modules
  • Also (needs to be done anyways): move all modules to corresponding repos.

Another idea how to avoid issues with PR1:

1. Rename baselibs needs id to avoid conflicts
2. Do the move
3. Do the cleanup is the score repo (i.e. move other module docs to their repos, cleanup feature architecture)
4. Rename needs ids back.

Acceptance criteria

• The Baselibs module documentation is migrated to https://github.com/eclipse-score/baselibs with preserving git history.
• Issues with linking to architecture elements is resolved in score repo

[4og]

@aschemmel-tech, @a-zw, please address this issue in the process and the infrastructure community.

[a-zw]

@OliverHeilwagen and me discussed a little further. This is what happens to this diagram if you delete the module/ folder in score repo:

This is a dynamically generated diagram and since inputs are missing, effectively nothing is displayed. (I also deleted a layouting hint manually but that is beside the point)

One proposal to avoid this "diagram reduction" would be to pull in needs.json files from somewhere else like a website: https://eclipse-score.github.io/score/main/needs.json This way the score platform repo would always show the latest and greatest. For contrast, the reference integration will show the properly integrated versions.

Alternatively, we can accept this "diagram reduction" as it still reflects the contents of the platform architecture.

The higher-level question is if this depiction how a feature is implemented is "prescribed by the platform" or if only "emerges from the integration"? In the first case, the depicted elements belong into the platform repository and not into the module repos. In the second case, it is correct that only the reference integration shows how modules compose to features.

[4og]

This change will be required in docs-as-code to support cross-repository linking: eclipse-score/docs-as-code#316

[4og]

This is paused until we agree on eclipse-score/score#2346