Fixing regression in composer post scripts

Fixes regression on Windows where composer update and composer install because the path is hardcoded to only work on *nix systems.

Partially reverts e9f13512

This caused two issues in Travis builds:
 * CMS builds were using
outdated framework dependencies. Example: https://travis-ci.org/silverstripe/silverstripe-cms/jobs/7718686
 * Modules weren't building
at all because the info in the lock file overwrote the custom
composer.json. Example: https://travis-ci.org/silverstripe/silverstripe-translatable/jobs/7726954

In addition, I don't agree with having lock files on release branches
(as opposed to tags), since it forces us to permantently update lock
files or work with stale dependencies even when on branches
(most likely not the developers intention).

NEW: Added post-install and post-update dev/build call.

Now that Composer has been fixed, self.version can be used as a dependency for framework
and cms in installer.  This simplifies our composer.json, and meanst that we can commit
composer.lock into the repo, as required.  An annoying piece of our release process has
been solved!

With this change, composer will automatically call dev/build after an update or install
command.  The main reason that this is 3.1-only is that previous releases would have
necessitated the use of 'sudo -u www-data', which is too environment-specific.

One thing that this may cause problems with is 'composer create-project' in an environment
without a _ss_environment file.  It will call dev/build, and dev/build will throw an
error.  That should be fixed in a subsequent commit.

HTML5 video file types.

case insensitive the assets/ allowed extensions for Apache

FIX: Put self.version in composer dependencies.

Now that https://github.com/composer/composer/pull/1883 is in Composer, self.version
will work as a requirement for framework & cms.  This will simplify the release
process a great deal.

Ultimately, the release of rc1 will be the place to test that, but it seems appropriate
to get this in there for that.

If it succeeds with 3.1-rc1, I'd suggest we backport to 3.0 and 2.4.

Remove require-dev section, composer doesn't handle it well

Any "composer require <module>" call will first call
a "composer update". This *automatically* includes dev requirements,
without providing a way to turn off this behaviour.
A workaround would be "composer require --no-update <module> && composer update --no-dev <module>",
but that drastically reduces the usefulness of the command
for our target audience (moderately technical devs).

In the end, the small faction of devs needing the dev dependencies
also know how to install them on their own. And having a local phpunit
build actually gets in the way more than it helps in case you have
it installed through PEAR already (can get really weird when using the
PEAR provided "phpunit" binary, but the autoloader finds the composer managed classes).

Ignore build-related files in "git archive" (fixes #8167)

IIS 7.5 does not like forward slash at the end of silverstripe-cache

IIS 7.5 does not like forward slash at the end of silverstripe-cache

Its now part of the core default YAML settings

Conflicts:
	composer.json

Checking out framework can often take longer than the default
(300 seconds). This gives a 10min limit to creating a new project.

Since SS3 keeps values in configuration, direct access
to known paths might expose them