Make development stack a variant of the production deployment

[surchs]

Context

We are developing an ecosystem of tools that all need to work together well. But we are developing them in individual repositories (for presumably good reasons). So we accept to do some extra steps during development to make our tools work together across repos.

In #27 we plan to adopt docker compose profiles so we can have a single compose recipe but have multiple deployment profiles. In a similar direction, we can use the docker compose extension syntax to make a second docker compose recipe that we use for development: https://docs.docker.com/compose/multiple-compose-files/extends/

This will ensure that dev and prod are always in sync but we can also have dev-specific deployment rules in the dev recipe. See for example the (probably temporary) repo: https://github.com/neurobagel/develop

Why

• So we can develop faster and more consistently
• So we develop in as close an approximation of production as we can
• To avoid problems that occur because of differences between our local dev environments and prod
• To make it easier to spin up an environment of tools with specific versions for development or testing

Outcomes

• The tool I am working on can interact with other NB tools without having to rely on public instances of these tools
• There is a one or two step process to go from a newly checked out repo to having all the required services running locally that my tool depends on
• I can locally edit, debug, test, view the tool I work on as it interacts with the other NB tools running locally

What

• Move information about development environment documentation#176
• Propagate tool stack configuration to all tools

[github-actions]

We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 75 days.
We have applied the _flag:stale label to indicate that this issue should be reviewed again.
When you review, please reread the spec and then apply one of these three options:

• prioritize: apply the flag:schedule label to suggest moving this issue into the backlog now
• close: if the issue is no longer relevant, explain why (give others a chance to reply) and then close.
• archive: sometimes an issue has important information or ideas but we won't work on it soon. In this case
  apply the someday label to show that this won't be prioritized. The stalebot will ignore issues with this
  label in the future. Use sparingly!