hbm-minigbm: Avoid or double-down on hbm-minigbm bindgen output location

The build.rs mechanism is intended to be used as an intermediate step to building some cargo-managed artifact (e.g. binary, rust lib, system lib).

As a consequence, the build.rs provides an OUT_DIR env variable into which all filesystem artifacts should be written.

That path is not intended to be externally meaningful, since cargo is only expecting to learn about it through one of the documented outputs of the build script.

I see that you've handled that situation by locating the generated header in the OUT_DIR and symlinking at <workspace>/target/<build-type>/hbm_minigbm.h, such that the integrating build system (ChromeOS's portage in our case) will be able to easily locate it for final installation.

My concern is that the symlink in <workspace>/target/<build-type> is already violating the "Scripts should not modify any files outside of that directory" principle, which hints that using build.rs may not be the most appropriate place to auto-generate the C header.

My suggestions are to do one of the following instead:

• decide that we are okay violating that principle, and avoid the need for symlink by writing hbm_minigbm.h directly to the $PWD, which will conveniently be /target/`
• avoid breaking the principle entirely, stop using build.rs, and move that invocation of cbindgen to the integrator's build system (portage) instead.

Of course, I'm happy to discuss the third option: don't change anything 😄