Use the more standard files xalloc.h' and xmalloc.c' instead of

Bison's `allocate.c' and `alloc.h'.  This patch was surprisingly
difficult and introduced a lot of core dump.  It turns out that
Bison used an implementation of `xmalloc' based on `calloc', and
at various places it does depend upon the initialization to 0.  I
have not tried to isolate the pertinent places, and all the former
calls to Bison's `xmalloc' are now using `XCALLOC'.  Someday,
someone should address this issue.
* src/allocate.c, src/alloc.h, m4/bison-decl.m4: Remove.
* lib/xmalloc.c, lib/xalloc.h, m4/malloc.m4, m4/realloc.m4: New
files.
Adjust dependencies.
* src/warshall.h: New file.
Propagate.

m4/malloc.m4

@@ -0,0 +1,35 @@
+#serial 3
+
+dnl From Jim Meyering.
+dnl Determine whether malloc accepts 0 as its argument.
+dnl If it doesn't, arrange to use the replacement function.
+dnl
+
+AC_DEFUN(jm_FUNC_MALLOC,
+[
+ dnl xmalloc.c requires that this symbol be defined so it doesn't
+ dnl mistakenly use a broken malloc -- as it might if this test were omitted.
+ AC_DEFINE_UNQUOTED(HAVE_DONE_WORKING_MALLOC_CHECK, 1,
+                    [Define if the malloc check has been performed. ])
+
+ AC_CACHE_CHECK([for working malloc], jm_cv_func_working_malloc,
+  [AC_TRY_RUN([
+    char *malloc ();
+    int
+    main ()
+    {
+      exit (malloc (0) ? 0 : 1);
+    }
+	  ],
+	 jm_cv_func_working_malloc=yes,
+	 jm_cv_func_working_malloc=no,
+	 dnl When crosscompiling, assume malloc is broken.
+	 jm_cv_func_working_malloc=no)
+  ])
+  if test $jm_cv_func_working_malloc = no; then
+    AC_SUBST(LIBOBJS)
+    LIBOBJS="$LIBOBJS malloc.$ac_objext"
+    AC_DEFINE_UNQUOTED(malloc, rpl_malloc,
+      [Define to rpl_malloc if the replacement function should be used.])
+  fi
+])