Make it easy for customers to consume upstream changes

## Context

At the time of writing 2025-02-25, the situation looks as follows AFAIS:
1. The docs do not explicitly explain how to setup version control for one's own code when building on QS. However, they implicitly point to taking a plain copy and starting from there on.
2. The QS is under heavy development; and lots of generally useful improvements are expected to land in the coming months.
3. For any customer building on QS, it thus makes sense to setup their own code such that it is easy for them to consume improvements as they land in https://github.com/digital-asset/cn-quickstart

## Request

I believe QS should:
1. Clearly explain how a customer should setup their codebase, so that they can easily consume changes from https://github.com/digital-asset/cn-quickstart
2. Ensure that QS development takes this guidance into account, and minimizes the kind of changes that are difficult to consume for customers.

The benefit of doing so is that improvements developed for one customer also benefit all other customers.

## Known Solution Options

Source code based reuse is fragile, but can nevertheless be made more efficient using a careful setup. We should decide whether to advise customers to maintain their code using:
1. a long-running branch of `cn-quickstart:main`
2. a file-based fork patched using git-scripts as done by the CN team for their Canton fork (see the [docs here explaining how this works](https://github.com/DACH-NY/canton-network-node/blob/main/README.md#bumping-our-canton-fork)). This is more flexible in terms of maintaining custom changes on top of the fork, but requires custom scripts.
ripts*:

Independently of these options reducing the amount of code in QS is benefical to minimize the number of changes that n common code in QS can be packaged into reusable libraries that are distributed via the appropriate package manager (NPM for .ts and Maven for .java).