Use new Apache and PHP binaries
Update binary vendoring steps in README

For Apache 2.2.25 and PHP 5.3.27.

As of now, the vendoring can now be done in a blank dyno rather
easily.  This process is now explained explicitly in the README.

The following is an overview of some of the changes:

* Rewrite recipes into bash-script form

* Make re-entrant (via clearing /app) for easier iteration

* Use variable substitutions for version, directory, and archive names
  instead of repeating chunks of each all over the place.

* Make downloading optional, again to assist iteration.

* Silence GNU Make steps via '-s' to quiet down builds (warnings are
  still shown).

* Rely on the bash-ism pushd and popd to be more robust to slight
  changes in relative paths that may occur in the future.

* Rely on the PHP-distributed version of PEAR/PECL rather than the
  apt-get install version, which has a more dubious set of default
  paths and can't be done in-dyno.  This makes the steps for dealing
  with 'APC' much simpler.

* Use default responses for prompts when building APC rather than
  prompting the builder.

* Sanitize cgi-bin of default Apache programs.

* Create binary-vendoring tarballs with the same name that they are
  intended to be uploaded as.

  Notably, name of the tarball and the directory contained within that
  tarball will not match because the contained directory is devoid of
  version numbering, unlike the name of the tarball.
Re-introduce support for mcrypt

It's not quite clear how mcrypt ever worked, but the symptoms suggest
that previous versions of this build pack were built on another Ubuntu
machine (as evidenced by use of apt-get install) and that PHP of that
era may have statically linked mcrypt.

This effectively vendored in mcrypt, even though such an intention is
not evidenced anywhere in the buildpack's history.

Subsequent builds that have been tweaked to work entirely in-Dyno have
thus lost this opportunity to statically link mcrypt, and furthermore
there are accounts on the web that mcrypt is dynamically linked
nowadays[0].

So, vendor mcrypt, ./configure-ing it as described by the manual
comments.

Furthermore, since this changes the PHP binaries even though it's the
same PHP version (the ./configure flags are different), introduce the
notion of "heroku_rev" that is used to signify such
sub-upstream-release versioning.  For simplicity, it is applied
uniformly to all emitted binary artifacts of the build, even though
some shouldn't change (in this case, Apache has received no changes
but has had its heroku_rev incremented anyway).

[0]: http://www.php.net/manual/en/mcrypt.installation.php