Broken handling of lwlocknames.h

Bjorn Munch reported off-list that this sequence:

unpack tarball, cd into it
./configure ...
cd src/test/regress
make

no longer works in 9.6beta2, where it did work in previous releases.
I have confirmed both statements.  The failure looks like

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security-fno-strict-aliasing -fwrapv -g -O1 -fpic -I../../../src/include -D_GNU_SOURCE   -c -o regress.o
regress.c
In file included from ../../../src/include/storage/lock.h:23,                from
../../../src/include/access/heapam.h:22,               from ../../../src/include/nodes/execnodes.h:18,
from../../../src/include/commands/trigger.h:17,                from regress.c:29:
 
../../../src/include/storage/lwlock.h:129:33: error: storage/lwlocknames.h: No such file or directory
make: *** [regress.o] Error 1

So this is some sort of fallout from commit aa65de042f582896, which
invented that as a generated file.

Perhaps the solution is to extend src/test/regress/GNUmakefile to know
about this file explicitly (as it already does know about
src/port/pg_config_paths.h).  But that seems rather brute-force; in
particular it seems like that does nothing to keep us from getting burnt
again the same way in future.  I wonder if we should modify
src/backend/Makefile so that it exposes a phony target for "update all the
generated include files", and then have src/test/regress/GNUmakefile call
that.  Or maybe there are other ways.
        regards, tom lane