https://wiki.civicrm.org/confluence/display/CRMDOC/Contributing+to+CiviCRM+using+GitHub

Make the warning about running Ubuntu installation as root slightly more dire.

and reminding everyone to always use buildkit

ref:
https://github.com/civicrm/civicrm-dev-docs/pull/217#issuecomment-314945998

ref:
https://github.com/civicrm/civicrm-dev-docs/pull/217#discussion_r127111272

Add links for phpstorm xdebug configuration

- General formatting improvements.
- Change  "Ubuntu 12.04 or 14.04" to "Ubuntu 12.04 or later" because the
  buildkit install script is clearly designed to work for later versions
  of Ubuntu.
- Relocate troubleshoot steps to after configuration steps (so the
  reader doesn't stop reading when they see "troubleshooting".
- Higlight post-installation steps.
- New instructions for manually ading webserver settings after running
  `amp config`.
- More troubleshooting help.

This was in the general "buildkit" page, and I think it fits better in
the specific "civibuild" page.

This is a direct copy-paste from one section of the guide to another,
without any edits. When someone is installing buildkit, these steps are
easy to miss if they're located in the civibuild file.

The doc mentions the page "Administer => System Settings => Cleanup Caches and Update Paths" as a way to clear caches. This is half-true: it does clear `templates_c` and the `civicrm_cache` table, but there are other things that it doesn't touch. (Compare `CRM_Admin_form_Setting_UpdateConfigBackend::postProcess` with the `CRM_Core_Invoke::rebuildMenuAndCaches`.)

IMHO, `UpdateConfigBackend::postProcess` should be patched to just do a general system flush (`civicrm_api3('System', 'flush', array())`) -- but (for now) the page is misleading and we shouldn't direct people there.

- Add details about how to do query logging to a table instead of a
  file.
- Put instructions into steps in chronological order.

We don't really need the two bulleted lists:
 * In context, the previous section should give hints about what this means.
 * If the context isn't clear enough, then the links provide more concrete description.

1.  The title for section `civicrm.settings.php; settings.php;
wp-config.php` is very long. Split the section -- a longer one
which discusses `civicrm.settings.php` in more depth, and a shorter
which discusses similar files briefly.

2.  Add a section for `civibuild.conf`.

This way MkDocs will be able to report errors for broken links

Done with:

perl -0777 -i -pe \
's@(?<!!)\[([^\]]*)\]\((?!https?://)(?!mailto:)(/(?:(?:(?:/(?![\)#]))|[^/)#])(?!.md))+)/?(#[^)]*)?\)@[$1]($2.md$3)@gm' \
`find . -name '*.md'`

Move them into the dedicated page on PhpStorm. Why? Tim has expressed
some concern about the potential difficulty (and slippery slope) of
starting to maintain IDE-specific docs. I like the PhpStorm page, but I
can see where he's coming from to a certain extent. As such, I think it
will be a good compromise if we can keep all the IDE-specific stuff as
consolidated as possible.

Migrated from the following two sources

https://github.com/civicrm/civicrm-buildkit/blob/d20229ac9f63aaf183687157a5e655c953b81f5e/doc/daily-coding.md#housekeeping
https://civicrm.stackexchange.com/questions/17717/how-do-i-upgrade-civicrm-on-a-local-site-that-i-installed-with-buildkit-civibuil/17721#17721

Not adding internal redirects because these pages are so new.

Based on discussion here:
https://github.com/civicrm/civicrm-dev-docs/pull/189