Improve compatibility with composer-based workflows

Problem/Motivation

For developers and testers (primarily) the github pull-request style workflow for Rules project development are challenging to integrate into a project that is using a Composer workflow.

Drupal-project frameworks drupal-project , Acquia BLT, and the hosting/deployment solutions like platform.sh all prefer to use site-recipes managed by composer.json - and the recent drupal.org instructions for Using Composer to manage Drupal site dependencies all expect us to be able to use
composer require drupal/rules

At the moment, we cannot do that and use or test the github-style dev branches of Rules from fago/rules or similar.

But! A few adjustments to the documentation for work-arounds could get us back on the same page!

Proposed resolution

Documentation

A couple of steps can be applied to your Composer-controlled Drupal project to instruct it to fetch the Rules module from an alternate (non-drupal.org locatipn.

Given an empty/clean (working) Drupal install built using https://github.com/drupal-composer/drupal-project, https://github.com/acquia/blt or similar...

Optionally fork a copy of the whole project, as per instructions - or just locate one of the working github branches that you need to use

Add that github repo as a specific remote repo (via composer)

composer config repositories.forked-rules vcs https://github.com/fago/rules.git

Have composer pull in the git checkout for us.

composer require --prefer-source drupal/rules:8.x-3.x-dev

rules/composer.json improvement

In order for a non-drupal.org drupal project to be fetched correctly, the projects composer.json should be complete. (Drupal.org actually fills in some missing stuff for us magically, but that cannot be relied on outside of that ecosystem)

Basically, we just need to ensure that all the project dependencies (this week that's typed_data) are explicitly in the composer.json

{
  "name": "drupal/rules",
  "description": "React on events and conditionally evaluate actions.",
  "type": "drupal-module",
  "license": "GPL-2.0+",
  "minimum-stability": "dev",
  "require": { 
    "drupal/typed_data": "*"
  }
}

In my experience this does not conflict with the d.o magic under the https://packages.drupal.org/8 server, and in the long term it will be expected for drupal projects to start defining their requirements using composer.json properly this way anyway.

... drupalcon code sprint is closing, I have other notes I'll just paste un-edited below...