This is being migrated to the SysAdmin guide as it is no longer required
for new installations

General themes/changes:

* Rewrite as a standalone page. This was previously content in the D8 page.
* Include the `curl ... cv.phar ...` command.
* Move discussion of the `core:install` options and common problems into collapsed admonitions.
* The "next level" docs for `cv core:install` are in the Dev Guide. Add links.
* Add a section for "Configure the site".
* Add a "Limitations" section.

* Use simpler language
* For optional commands, link to relevants docs.

* There are a lot of details that can live inside collapsed sections.
* Several of the asides are basic gotchas that would affect any effort to
  run composer on D8. Combine these into one collapsed section,
  "Quick and dirty introduction to D8 with composer"
* The headings "Expert mode"/"Guided mode" are weird to me -- because
  (1) "Expert" identifies the most common/easiest variation of the command,
  and (2) "mode" suggests software-mode, but it's actually a different
  presentational style for the documenter. Instead, just give one
  procedure - and provide drill-down options for explanation.

* As in the previous commit (D7/BD), there are two workflows, web-based an CLI-based.
  Put them in collapsible admonitions.
* Reorganize the warnings for the web-based workflow.
* The D8 section had more discussion of the CLI steps. Move these over to the `cli-cv.md` file.
  They'll still need more editing, but it makes sense for this more advanced+verbose
  use-case to have a separate file.

* There are two distinct workflows, web-based and CLI-based. Put them in collapsible admonitions.
* For web-based flow, use "activate-first" / "civicrm-setup" workflow instead of
  the `sites/all/modules/civicrm/install/yaddayadda` workflow
* Remove older warning module-activation. It's no longer a bad thing if an admin
  activates on their own accord.

* Make it easier to skip past the stuff about the developer guide
    * Change the header "Similar alternatives" to "Alternative: Civibuild for developers"
    * Mark the section collapsible (default closed).
* To make the styling of the front-matter more consistent, update "About this document"
  to also be collapsible (but default open).

OK, so you go through a bunch of steps and come to these instructions:

> There should now be a CiviCRM link in your Drupal menu.  Click that link and
> the CiviCRM Menu, Shortcuts, Search and New Individual Blocks should appear.
> You can now explore CiviCRM end-user features and begin configuring CiviCRM
> for your site/organization needs.

This should be the end of the installation guide. But, if you skim the TOC,
it keeps on going!

I *think* what's going on here is that people wanted to add some sections
which are sort of independent of the main flow of installation.

These probably should be moved/referenced in some other way, but I don't
really want to think too hard.  This commit just mitigates the confusion
a bit by setting the subsequent sections (re:MySQL encryption and troubleshooting)
under the heading "Addenda".

When the first heading of the document says...

> "Scope of this guide and alternative installation methods"

It breaks my English parser, and I start to cry. Just a little. On the inside.

1. Use sentence-case.

2. There will have been less of the future-past-perfect.

3. Conjugate actively.

1. Use sentence-case per style-guide (all files)
2. Don't need to explain every detail in the title (WP file)

1. Title is more specific/wordy than it needs to be.

2. Capitalizing the page title ("Configuration Checklist") is correct,
   but (as a reader skimming) it *looks* wrong because it doesn't match
   the norm and it lacks anything (quotes/italics/bold) to set it aside.

Just use a plain noun instead of a proper noun.

1. Resources in redundant.
2. The other section headings have active verb-phrase. This is a little closer.
3. The dash in "Trouble-shooting" is inconsistent. It's not wrong per se, but
   it's a little unusual, and it should be consistent with the title of
   liked page.

1. Use sentence-case

2. Don't be so wordy.  The paragraph explains this stuff - you don't need
to put the whole explanation into the TOC.

Before:

* Each CMS chapter uses slightly different headings and anchors
  for the same conceptual steps.
* Several of them try to distinguish when you do/do-not need translations,
  but they're arbitrarily different.

After:

* Each CMS chapter uses the same headings and anchors.
* If there was a different anchor before, then that anchor is still valid (but it is no
  longer visible or primary).
* It still tries to distinguish when you do/do-not need translations, but
  the language is simpler and more consistent.

The list of requirements is hard to take in at a glance. This adds a section that
you can read at a glance. It's obviously not as thorough as the main requirements,
so it's only presented as a summary-recommendation.

This repo currently has 16 markdown files, of which 8 have `CR` endings and
8 have `CR-LF` endings.  For comparison, the dev-docs and sysadmin-guide
have strictly `CR` endings.