Support safe migration from production to non-production instances

New approach from Tim as discussed on civicrm-dev list with subject 'core support for deployment environments, CRM-18231' May 20-24, 2016:
1. Admin edits civicrm.settings.php to set the default environment.
2. Admin reviews civicrm.settings.$ENV.php. There’s a bunch of defaults (along the lines of https://gist.github.com/totten/ccefde8df34af41d02decd9536566218 ), but they can be edited. Initially, do not support [domain] array index for now as this is not supported elsewhere in civicrm.settings.php, and when required during overriding process eg for payment processor selection, use the domain_id specified in civicrm.settings.php.

Joe adds:
3. The relevant civicrm.settings.$ENV.php is loaded after civicrm.settings.php during bootstrap, so it can be used to (eventually) override any of the values in the latter. For illustrative purposes, civicrm.settings.production.php and civicrm.settings.staging.php will be included in same directory as civicrm.settings.php on initial install and upgrade, and will have all overrides commented out.
4. Support disabling of sending emails by overriding the settings for outbound email at Administer > System Settings > Outbound Email.
5. Support overriding any of the field values of a payment processor using the machine name for the processor and the fieldname for the value to be overridden, eg:
// see http://home.iatspayments.com/developers/test-credentials
$civicrm_setting['payment_processor']['My_IATS']['user_name'] = 'TEST88';
$civicrm_setting['payment_processor']['My_IATS']['password'] = 'TEST88';
where 'My_IATS' is civicrm_payment_processor.name value.

Original description follows:

Full spec: https://wiki.civicrm.org/confluence/display/CRMDOC/Moving+CiviCRM+instance+from+production+to+staging

This feature will allow a new variable in settings that can be set in civicrm.settings.php and will provide ability for extensions to be able to hook in to changes from being production to being non-production so they can do their own thing if necessary.
Implementation:
1. Create a new hook that extensions could implement.
2. API for settings.
3. Add a field for this setting onto the Debug page in admin.
4. Add a CONST in civicrm.settings.php with a value that would be read and overrides the db value and shows the value from the settings file in the UI.
5. If there is a value set in civicrm.settings.php then it overrides stuff from browser.
6. If there is no value set in civicrm.settings.php then default in browser is Production = TRUE, and it can be changed from browser. However, if there is a value, either Production or Non-production, in settings file then the field in the form is visible but not editable i.e disabled and we will display a info message beside indicating that it has been overridden in settings.