This is a simple administrative update to the headers. It was generated with the command:

```
rgrep '| CiviCRM version 4.7' CRM/ Civi ang api bin extern install/ settings/ templates -l \
  | xargs sed -i'' "s/| CiviCRM version 4.7/| CiviCRM version 5  /g"
```

Tthe inclusion of `|` aimed to avoid matching any non-header text (e.g. inline docs that
mentioned the version incidentally). But then I did a looser search and for just

```
rgrep 'CiviCRM version 4.7'
````

and manually patched the remainder.

Note: I'm not really keen on doing this every month, so I relaxed the header
statement -- instead of `CiviCRM version 5.0`, it's just `CiviCRM version 5`.

This is a partial commit which covers the best tested section of these & establishes the new functions.

I didn't want to make the commit too daunting. The bin file probably has not been used in years
hence all the require_once calls :-)

This script is little-used but sometimes helpful when juggling multiple
versions in the same source-tree.

Arguably, it's sufficient to check for administrative privileges...  since
an administrator can do this kind of damage anyway...  but this use-case is
so broad, dangerous, and uncommon that it really shouldn't be available
unless you take extraordinary measures.

It's tempting to remove the file entirely, but some upgrade workflows don't
properly handle deleted files, and some users may still want access to this
code so that they can run it themselves.

The DatabaseInitializer is called during first boot
(`CRM_Core_Config::singleton()`) and runs `system.flush session=1
triggers=1` which (among other things) enumerates modules (including CMS
modules).  In standalone boot protocol, that means it runs before
`CRM_Utils_System::loadBootstrap()` (which means that CMS modules
cannot be enumerated yet).

A simple work-around is to always boot the CMS first (before
`CRM_Core_Config::singleton()` or `DatabaseInitializer` runs).

1. This addresses the error [PHP Fatal error:  Call to undefined function db_query() in /opt/buildkit/build/mytestbuild/sites/all/modules/civicrm/CRM/Utils/System/DrupalBase.php](http://civicrm.stackexchange.com/questions/11972/regen-sh-call-to-undefined-function-db-query/11986#11986).

2.  Generally, the goal here is to produce `civicrm_generated.mysql`, which
is used on any/all CMS's to initialize the Civi database.  If the generation
were really dependent on Drupal 7, then we wouldn't be able to use that
output on other CMS's, right?  Thus I'm hopeful that we can generate
`civicrm_generated.mysql` with any `CIVICRM_UF`.  And the `UnitTests` UF has
fewer dependencies/interactions.

3. Since `GenerateData.php` is running in a dummy CMS, we can remove
these weird mock-drupal-functions.

4. To test, I ran `regen.sh` and compared the output with the old one.
All the changes looked like random-data (`civicrm_contact`, etal) and
not structural data (`civicrm_option_value`, etal).

The original `regen.sh` script drops the table `zipcodes` after creating it.
That works fine in normal execution (when `regen.sh` finishes without
erorr).  But if there is an error, then the table gets left in the DB -- and
creates a conflict when you try re-run `regen.sh`.

This patch does a 'drop-create' so that subsequent runs will work despite a
previous error.

The null array static is a work-around for pass-by-reference signatures but the executeQuery no longer requires it.

It's not actually 'just' tidy-up as the array can become contaminated, leading to hard to diagnose bugs.

Note there is one instance of a similar tidy up on contribution::create in this - the  parameter is no longer mandatory & we call this function so often I feel confident about removing the stray & too

Moved system flush from setup.sh to first-run; added permissionEmails() and upgradePermissions() in CRM_Core_Permission_Drupal8.

bin/csv/export.php

Conflicts:
	bin/cli.class.php

Several subsystems were initialized on-demand. This had a weird side-effect
where the container would start initializing and call another service, which
would then (indirectly) try to initialize another container. The two container
instances would not be the same.

This revision enforces a more carefully considered sequence of events (which
will be documented in the wiki page, "Bootstrap Reference").

For a large number of settings, defaults are declared twice -- once in
`xml/templates/civicrm_navigation.tpl` and once in `settings/*.php`.  In
many cases, these are identical/redundant, but there are a couple where the
defaults diverged.

I believe the `civicrm_navigation.tpl` values have generally taken precedent
on new installations, so this commit revises `settings/*.php` to fix any
discrepancies.