Document "advanced" Composer-based approach to hosting farmOS [#3245733]

Problem/Motivation

This is not urgent, but I wanted to open an issue to track it, since it's come up a few times now... for recent context, see: https://farmos.discourse.group/t/enabling-phpmailer-in-2-x-docker-image/...

Currently our “Installing farmOS” documentation outlines 2 “recommended” approaches to managing the farmOS codebase:

Using Docker images.
Using packaged releases.

Both of these approaches are aimed at "basic" deployments, currently. The former for hosts who have access to Docker, and the latter for supporting hosts who do not (eg: deploying on shared hosting environments).

There is a third way, which can be considered the "advanced" approach: Using Composer.

One of the primary reasons for an "advanced" approach is to add addition modules to your deployment.

Simple modules can be downloaded directly as tarballs and placed in sites/all/modules in "basic" deployments, but this doesn't cover modules which have upstream dependencies on other packages declared in their composer.json files. For those, it is necessary to require them via Composer, by declaring them as dependencies in the root composer.json file.

For "basic" deployments, the root (aka "project") composer.json file is auto-generated inside the Docker container, using the official farmOS/composer-project template: https://github.com/farmOS/composer-project

For "advanced" deployments, the site/server administrator can take over control of the root composer.json file themselves. This allows more dependencies to be added at the "project" level, so that they become dependencies of the deployment, as opposed to dependencies of farmOS itself.

Managing this root composer.json file can be done in a few different ways, so let's use this issue to document all the various considerations, and decide on one approach that we can included under our "recommended" approaches in the official farmOS documentation.

We don't need to cover every possible option - that can be left to the creativity of downstream maintainers if they want - Drupal+Composer+Docker provides a lot of flexibility if you are familiar with all the possibilities. We just need to provide the basic options in our docs, I think.