Signed-off-by: Kevin Cristiano <kcristiano@kcristiano.com>

required by civicrm/civicrm-wordpress#160

More details about schema updates

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

Redirect for old API architecture page

Consolidate buildkit requirements (basics/requirements.md, tools/buildkit.md)

Fix warnings on URLs given off by mkdocs

Add documentation for tags

api/*/changes.md - Fix broken link that blocks publication

There used to be a wiki page specifically about configuring the PATH to
include third-party `php` binaries. The link says it goes there, but it
actually goes to something completely different (PHP coding standards).

1. I believe the list of system requirements in `requirements.md` and `buildkit.md` were originally copied from the same
place, but they've drifted apart arbitrarily.  This reconciles them by:

    * Copying some of the details in `buildkit.md` over to `requirements.md`
    * Removing the list from `buildkit.md`
    * Replacing with a hyperlink and a blurb about the importance of system requirements

2. When reading the "Generic" section, my eyes glazed over at the list of requirements.  There are really just two
instructions (`git clone...` and `./bin/civi-download-tools`). Considering that `civi-download-tools` has
some diagnostics built-in (and is patch-welcome for more), it seems to belabor the point by reproducing the
entire list under `buildkit.md#other-platforms`.

dev/core#1615 - Import civicrm-setup docs

Add docs on obsolete extensions

Correcting the path in 'Generate a skeletal extension'

Tweak api architecture & changelog and move hook changelog to its own page

Add explanation about core extensions to docs

corrected typo in extension directory structure

@totten @seamuslee001 @colemanw @MikeyMJCO @twomice

* 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.

Update hook_civicrm_entityTypes.md