Migrate installers to "setup" API

Overview

The aim of this filing is to do a round of consolidation/reconciliation in the Civi installer code: get rid of install/*.php and instead use civicrm-setup. The latter offers:

• Better APIs and better organization - e.g. you can drill-down on most installation tasks by browsing the plugins (esp installFiles and installDatabase); inspect the list of event-listeners; and programmatically manage plugins.
• More sensible UX - the list of options is more useful for a new admin initializing the system.

Some background: https://civicrm.org/blog/totten/developers-revising-the-civicrm-installer-library-cli-wordpress

Use-cases

There are several different use-cases for performing installation; most permutations of the following variables are fair:

1. UF/CMS: Civi can be installed on top of Backdrop, Drupal 6/7/8, Joomla, WordPress.
2. Medium: Civi can be installed through:
   • Web installation screens (e.g. civicrm/install/index.php and the Joomla installer)
   • CLI installers (e.g. cv core:install)
   • Scripts/packagers (e.g. Drupal "profiles", civibuild, docker)
3. Options: Civi can be configured with:
   • CMS DB or separate DB
   • Empty data or demo data
   • "Components" (enabled/disabled)
   • "Extensions" (enabled/disabled)
   • "Settings" (defaults/overrides)
   • Path/URL definitions (defaults/overrides)

Current behavior

There are separate installers. There are number of arbitrary differences and un-DRY things.

Proposed behavior

All installers use a PHP API for Civi installation.

Process

There are several things to consolidate here; it's not just one commit or PR. Suggested tasks (in approximate order):

• Move code from civicrm-setup.git into civicrm-core.git (done, #16618):
  • civicrm-setup started as a separate repo so that I could iterate quickly in the early stages. However, as this gets rolled into more use-cases, it's likely to get referenced in more places (e.g. civicrm-drupal-8.git, civicrm-drupal.git, civicrm-wordpress.git, civicrm-backdrop.git), and it is also reasonable to expect a few small patches. Unfortunately, juggling small patches in that arrangement would be mentally draining. Migrating the code into civicrm-core.git will remove one layer of complexity.
  • Like the API framework or DB framework, the installer is sufficiently important to civicrm-core go into the main repo.
• Move docs from civicrm-setup.git into civicrm-dev-docs.git (done, see Dev Guide: Setup Reference)
• Update Civi-WordPress:
  • (Phase 1) Switch the default from install/ UI to civicrm-setup UI. (It's currently available opt-in. Switch to opt-out.)
  • (Phase 2) Update wp-cli/civicrm.php so that WP-CLI uses civicrm-setup API.
  • (Wishlist/Future) Ensure that all tasks (e.g. registering base-pages or permissions) are called in WP-oriented *.civi-setup.php plugin.
• Update Civi-D8/D9
  • (Phase 1) Update civicrm.install to call civicrm-setup APIs (related: https://github.com/civicrm/civicrm-drupal-8/pull/37)
  • (Phase 2) Update civicrm.drush.inc so that D7/BD use civicrm-setup API.
• Update Civi-D7/BD
  • (Phase 1) Update install/index.php so that D7/BD default to loading the civicrm-setup UI. The sysadmin docs may continue pointing admins to install/index.php. Optionally, allow one to use a parameter to opt-out and get the old UI.
  • (Phase 2) Update civicrm.drush.inc so that D7/BD use civicrm-setup API. (related: https://github.com/civicrm/civicrm-drupal/pull/679)
• Update Civi-Joomla
  • (Phase 2) Update to use civicrm-setup API
• Ignore Civi-D6
• Update civibuild
  • (Phase 2) Switch implementation from civicrm_install() to civicrm_install_cv() (related WIP: https://github.com/civicrm/civicrm-buildkit/pull/673)
  • (Wishlist/future) Remove old implementation
  • (Wishlist/future) Convert civicrm_make_test_settings_php() to a civicrm-setup plugin. Document an installer-option to initialize test/dev-harness.
• Remove all opt-outs. Final pass to double-check/remove all remaining logic from install/ folder
  • (This is the last step, after all the others.)