build: compile_et rules for parallel make

build: compile_et rules for parallel make

Change all makefile rules which run compile_et in order support parallel
make.  The compile_et generates two outputs, so special care must be
taken in rules which run compile_et.

All the rules for compile_et have been changed to the form:

    foo.c foo.h: foo.et
        compile_et foo.et -h foo
    foo.h: foo.c

The above rules are equivalent to:

    foo.c: foo.et
        compile_et foo.et -h foo

    foo.h: foo.et foo.c
        compile_et foo.et -h foo

therefore a parallel make will serialize the builds of foo.c and foo.h,
and should detect that the second is no longer needed once the first is
over.  This form works since foo.et is not a phony target, and does not
depend on a phony target.

Previously, the rules for compile_et were of the one of the two forms:

    a)  foo.c foo.h: foo.et
            compile_et foo.et -h foo

or

    b)  foo.h: foo.c
        foo.c: foo.et
            compile_et foo.et -h foo

Form a) is problematic for parallel makes, since it is equivalent to:

        foo.c:
            compile_et foo.et -h foo
        foo.h:
            compile_et foo.et -h foo

In a parallel make, compile_et will be run concurrently, clobbering
each other's output files.

Form b) is better, but is problematic when foo.h is removed, since foo.h
will not be updated.

Thanks to Russ Allbery for pointing out the automake documentation which
describes issues with commands that produce multiple outputs, and
portable solutions.

http://www.gnu.org/software/automake/manual/automake.html#Multiple-Outputs

Reviewed-on: http://gerrit.openafs.org/10237
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
(cherry picked from commit dbf68229c6c90d65781fdc16565dd1e9b56248c0)

Change-Id: Ibb5a5e9c85245d716b1b203a15adbe5c87d860b7
Reviewed-on: http://gerrit.openafs.org/10310
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>