aclocal: just warn if the primary local m4 dir doesn't exist (don't error)

aclocal: just warn if the primary local m4 dir doesn't exist (don't error)

Related to automake bug#13514.

Every package which does not need to have the local m4 macro
directory pre-existing in the version control system (because
e.g., it does not have nor need any private m4 macros) would
fail during the "autoreconf -vfi" phase if AC_CONFIG_MACRO_DIRS([m4])
is specified in configure.ac (it could be to instruct tools like
'autopoint' and 'libtoolize' to use 'm4' as the local directory
where to install definitions of their m4 macros, and to instruct
aclocal to look into it).  The failure would go like this:

  autoreconf: Entering directory `.'
  autoreconf: running: aclocal --force
  aclocal: error: couldn't open directory 'm4': No such file or directory
  autoreconf: aclocal failed with exit status: 1

The problem is that when 'aclocal' is run for the first time during
'autoreconf', the directory 'm4' does not exist yet.  It will be
created by e.g., 'libtoolize' or 'autopoint' later on.  During the
second 'aclocal' run, the 'm4' directory exists and aclocal does not
complain.

To work around this issue, we degrade the error to a simple warning.
The warning is still quite useful when aclocal is run by hand - so
we are not removing completely.

See also:
<http://lists.gnu.org/archive/html/bug-automake/2013-01/msg00115.html>
<http://lists.gnu.org/archive/html/automake-patches/2010-02/msg00030.html>
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663>
<https://bugzilla.redhat.com/show_bug.cgi?id=901333>

* aclocal.in (SCAN_M4_DIRS_SILENT, SCAN_M4_DIRS_WARN)
(SCAN_M4_DIRS_ERROR): New constants.
(scan_m4_dirs): Change the second parameter name to $ERR_LEVEL to
better reflect new semantic. Use new constants.
(scan_m4_files): Adjust to reflect the new 'scan_m4_dirs' semantics.
* t/aclocal-macrodir.tap: Adjust.
* t/aclocal-macrodirs.tap: Likewise.
* THANKS: Update.
* NEWS: Likewise.

Suggested-by: Ben Pfaff <blp@cs.stanford.edu>
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>