Expose all major CiviCRM repos as Composer packages

CiviCRM is maintained as several git repositories. These git repositories should have "composer" metadata and be listed on packagist.

== Background / Goals ==

• For Drupal 8, we have a strong requirement for distributing CiviCRM via composer (to allow composer to reconcile the requirements; see CRM-17652).
• For D7/WordPress (and probably others), there are some adhoc communities-of-practice around composer-based builds. Supporting composer-based builds could provide an elegant way to manage extension dependencies on any CMS.

== General Design ==

An ideal design might be something like this:

For a D8 user to download Civi, they would simply run "composer require civicrm/civicrm-drupal" or "composer require civicrm/civicrm-drupal:~8.x-4.7.22".

I think there is a problem with this, though: "self.version" might be too literal. (How would you say that "civicrm/civicrm-drupal@8.x-4.7.22" depends on "civicrm/civicrm-core" at the same version but without the "8.x-" prefix?)

Unless there's a nice way to handle that, I think we should just omit the version requirements from CMS modules. The installation command would be "composer require civicrm/core civicrm/drupal" or "composer require civicrm/core:~4.7.22 civicrm/drupal:8.x-4.7.22".

Tip: I'm hoping to avoid making updates to "composer.json" or "composer.lock" every time we branch/tag. However, if it is necessary, this will probably be the place in the workflow to do it: doc/4.7-rc.md.

== "civicrm/{foo}" vs "civicrm/civicrm{foo}" ==-

In the tables above, you may notice that the Github names and Composer names are slightly different. This is because they have different semantics/cultures:

• In Github, it is normal for each developer to make a new project name. Suppose  downstream developer "alice" forks "civicrm/civicrm-drupal". Her project would be named "alice/civicrm-drupal". The prefix "civicrm" is a necessary quirk to avoid conflicts/ambiguities. (Ex: if she forked "civicrm/drupal" and "drupal/drupal", then "alice/drupal" would be ambiguous.)-
• In Composer/Packagist, it is abnormal for each developer to make a new project name. Even if Alice is forking an existing project, the Composer/Packagist docs say that she should keep the project name but override the repo address. (This is important if you consider that composer needs to resolve dependencies from many different packages. Renaming would have ripple-effects in changing other projects.)

= dsnopek's list of things remaining todo =

Since it appears this is going to get some more attention soon, here's a list of the composer-related issues from CRM-17652 that haven't been resolved yet, which will need to be resolved to support doing composer require civicrm/drupal (and only that!) to install CiviCRM into a Drupal 8 site:

• "civicrm-packages" installable via composer: It'll end up under vendor/, so CiviCRM code will need to be changed to find it)
• Bower dependencies installable via composer: discussed in detail here - the easiest solution is just committing them to the repo, but there are several other options
• The other stuff created by the build process will need to get into composer managed sites somehow: discussed in detail here where @totten gives different options for the different things
• (not previously discussed) Easily allow 'vendor' directory not under the webroot: It's best practice keep the 'vendor' directory outsite the webroot, but CiviCRM has lots of web assets in there. All our D8/CiviCRM sites are doing this via a build process that's rsync'ing the assets (but not most of the PHP code) into the webroot and setting the CiviCRM "Resource URL" there, which mostly just works (we have a WYSIWYG-related patch I still need to contribute). However, ideally, there'd be a class included that people could reference in their composer.json do this copying as part of installing CiviCRM via composer, rather than needing a separate build process like we're using.