In Linux build system, build targets and installation targets are
separated.

Examples are:

 - 'make vmlinux' -> 'make install'
 - 'make modules' -> 'make modules_install'
 - 'make dtbs'    -> 'make dtbs_install'
 - 'make vdso'    -> 'make vdso_install'

The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.

We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.

If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.

Anyway, I believe it makes sense to split the header installation into
two stages.

 [1] 'make headers'
    Process headers in uapi directories by scripts/headers_install.sh
    and copy them to usr/include

 [2] 'make headers_install'
    Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include

For the backward compatibility, 'headers_install' depends on 'headers'.

Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.

Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.

Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>