Fix for _AC_AM_CONFIG_HEADER_HOOK (CONFIG_HEADER stamp file creation) bug

[Sander Niemeijer]

This replacement for the _AC_AM_CONFIG_HEADER_HOOK macro (located in 
m4/init.m4) fixes an incorrect naming issue of stamp-h* files when only 
specific headers are recreated through config.status.

The problem can be reproduced by creating a configure.ac file 
containing:
---
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_HEADERS([someotherfile.h])
---
When configure first creates the .h files from the .h.in files the 
proper stamp-h1 and stamp-h2 files are created. Now modify 
someotherfile.h.in and call 'make' again. This results in a call to 
'$(SHELL) ./config.status someotherfile.h' to recreate someotherfile.h. 
However, config.status now incorrectly creates a stamp-h1 file instead 
of stamp-h2 file.

The following proposed replacement for _AC_AM_CONFIG_HEADER_HOOK fixes 
this issue:
---
AC_DEFUN([_AC_AM_CONFIG_HEADER_HOOK],
[_am_stamp_count=0
_am_local_stamp_count=0
for ac_stamped_file in $config_headers : ; do
  _am_local_stamp_count=`expr ${_am_local_stamp_count} + 1`
  test $ac_stamped_file = $1 && _am_stamp_count=$_am_local_stamp_count
done
echo "timestamp for $1" >`AS_DIRNAME([$1])`/stamp-h[]$_am_stamp_count])
---

P.S. A better replacement would be to have the $config_headers list 
passed along as variable to the _AC_AM_HEADER_HOOK macro. This would 
keep the macro independent of any outside variables. But on the other 
hand this would mean that the every invocation of this macro should be 
changed and I don't really know whether that could brake any other 
packages (like e.g. autoconf) that might depend on this macro. Anybody 
any idea about that?

Regards,
Sander Niemeijer