Instead of patching configuration headers template generated by
the given tools - autoheader, this moves patching these symbols to
the configure step before creating and invoking the config.status
and before the configuration header file is generated from the
patched template.

Closes GH-4374

Commit 4e7064d173d2b5b22e159fcf52d22b10213b67b8 removed the usage of
`aclocal.m4`. When using Git repositories, many times cleaning of the
generated files is not done prior to running phpize or buildconf. For
example:

  git clone git://github.com/php/php-src
  cd php-src
  git checkout PHP-7.3
  ./buildconf
  ./configure
  git checkout PHP-7.4
  ./buildconf # -> warnings
  ./configure # -> errors

To not accidentally include `aclocal.m4` file in the generated configure
this enhances build system experience a bit more by removing aclocal.m4
file prior to start building configure file using phpize or buildconf.

The acinclude.m4 file is in a usual Autotools build processed with
Automake's aclocal tool. Since PHP currently doesn't use Automake and
aclocal this file can be moved into the build directory. PHP build
system currently generates a combined aclocal.m4 file that Autoconf
can processes automatically.

However, a newer practice is writing all local macros in separate
dedicated files prefixed with package name, in PHP's case PHP_MACRO_NAME
and putting them in a common `m4` directory. PHP uses currently `build`
directory for this purpose.

Name `php.m4` probably most resembles such file for PHP's case.

PHP manually created the aclocal.m4 file from acinclude.m4 and
build/libtool.m4. Which is also not a particularly good practice [1], so
this patch also removes the generated alocal.m4 usage and uses
m4_include() calls manually in the configure.ac and phpize.m4 files
manually.

- sort order is not important but can be alphabetical
- list of *.m4 files prerequisites for configure script generation
  updated
- Moving m4_include() before AC_INIT also removes all comments starting
  with hash character (`#`) in the included files.

[1] https://autotools.io/autoconf/macros.html

Autoconf defines PACKAGE_* symbols:
- PACKAGE_NAME
- PACKAGE_VERSION
- PACKAGE_TARNAME
- PACKAGE_STRING
- PACKAGE_BUGREPORT
- PACKAGE_URL

and appends them to the generated config.h.in files. With AC_INIT change
via afd52f9d9986d92dd0c63832a07ab1a16bf11d53 where package version, URL,
bug report location and similar meta data are defined, these
preprocessor macros are then non empty strings in the generated
configuration header file. When using phpize, PHP shares the config
files in extensions, warnings of redefined macros appear, such as:
- `warning: 'PACKAGE_NAME' macro redefined`

This patch now disables these non utilized symbols in the generated
config header files.

Better practice would be to include only API specific headers where
needed but this would require even more refactorings. Some extensions
such as pcre, pgsql, and pdo_pgsql solve this issue by undefining some
of these symbols before including the library configuration headers in
the code also. Because these symbols can be defined by any library which
uses Autotools.

Additionally, the unused PACKAGE_* symbols were cleaned for the bundled
libmbfl library and with this patch not needed undef code removed.

These files can be stored in the build directory instead of bloating the
project root directory.

These scripts are part of Automake [1] and are in current *nix build
system not used anymore nor empty files need to be created.

[1] https://www.gnu.org/software/automake/manual/html_node/Auxiliary-Programs.html

The PHP_EXTENSION macro was used before the introduction of the updated
build system in the 9d9d39a0de3bec962c343051011f5a2ed7d7b242. The
extensions at that time possibly still used the Makefile.in and Automake
and the PHP_EXTENSION macro has been replaced with the PHP_NEW_EXTENSION
macro.

Today, the once deprecated macro can be removed in favor of only
PHP_NEW_EXTENSION macro.

The Autoconf macro AC_CONFIG_AUX_DIR can set the location of the
auxiliary build tools such as config.guess, config.sub, and bundled
libtool scripts and moves these bundled files from the root directory
to the build subdirectory.

Additionally some changes in this context or as a part of obsoletion:
- The LT_TARGETS variable in build/build2.mk file was once used as a part
  of the Automake step. It's not used anymore and has been refactored to
  separate makedist script directly.
- ltconfig is not used anymore since libtool 1.4+
  cf8d1563c27a70fdd24055c1e80218ec7b5962d6
- phpize file locations for the config.guess, config.sub, and ltmain.sh
  has been refactored accordingly.

The latest version of freetype2 does not install freetype-config by
default, but pkg-config support has been there for approximately 15
years. In order to reliably detect freetype2, pkg-config *must* be used.

See:
https://savannah.nongnu.org/bugs/?53093
https://bugs.php.net/bug.php?id=76324

The `mkdep.awk` file was part of the previous *nix build system and was
used to create a .deps file with a list of dependencies that could be
processed by Automake further on.

Newer build system was done via 9d9d39a0de3bec962c343051011f5a2ed7d7b242
and outdated files removed via 22815419f8c5da902971d3aa12f2cbfcc3b41aff
so the current file in the PHP source code is not used anymore.

Additionally, the *.slo files were processed by this file. The *.slo
files also used to be generated by older libtool so today, these don't
get generated anymore.