* Rephrase now that it's in core
* Skip the steps for checking out a custom repo. The code now comes with core.
* Change example paths to be more readable
* Misc copyedit

* Rephrase now that the code is in core
* Fix some links (since the docs are now split from the code)
* Move "Key features" above "General design" since it's quicker to read

1.  Don't describe the `.use-civicrm-setup` protocol.  This is used in one
    place, and it's likely to get inverted in the near future.

2.  When customizing the model, most values shouldn't be passed directly
    into `init()`.  Let `init()` detect its defaults.  Then call
    `$setup->getModel()` and customize that.  (I had tried customizing via
    `init()` when first implementing `cv core:install` and found it less
    useful.  There was also a support issue when someone else tried the same
    thing.) This pattern should work more intuitively.

Out of date even for v3, and supplanted by v4 architecture page.

Co-Authored-By: Tim Otten <totten@civicrm.org>

Add in documentation on setting and retrieving contact settings using the Civi:: facade and also add in note about the deprecation of the ::setItem function

Add in examples and details on delayed queue tasks and running queues through an API style mechanism

Co-Authored-By: Mikey O'Toole <mikey@mjco.uk>

Co-Authored-By: Mikey O'Toole <mikey@mjco.uk>

Co-Authored-By: Mikey O'Toole <mikey@mjco.uk>

Co-Authored-By: Mikey O'Toole <mikey@mjco.uk>

Co-Authored-By: Mikey O'Toole <mikey@mjco.uk>

Co-Authored-By: Mikey O'Toole <mikey@mjco.uk>

Co-Authored-By: Mikey O'Toole <mikey@mjco.uk>

Help for civicrm.private, civicrm.log, civicrm.compile.