Add buck2 rules that implement CMake's configure_file() behavior.

[zjturner]

This adds a set of rules that implement CMake configure_file() semantics, significantly easing the burden of writing native buck builds for libraries whose native build systems are written in CMake (or other configure-like systems).

Typically, such build systems will run a step before the build begins that determines values for all of the things it considers important. Then it will output a header file (or otherwise modify the build in some way, for example by adding preprocessor defines) that contains preprocessor defines, typedefs etc that contain definitions based on the values that were determined earlier.

Examples of popular libraries that depend on this kind of functionality are curl and nghttp2, but there are (very literally) thousands that someone could name. Implementing native buck builds for these libraries pretty much require rules such as those implemented in this PR.

There are two basic categories of meta-rules implemented in this PR, and then one "real" rule that does the actual work.

generic value rules hardcode values about your toolchain (or, really, anything at all) that would otherwise be computed by something like autoconf, configure, or CMake itself. For example, these systems may try to detect whether or not your toolchain has ssize_t defined, or the size of an integer. These systems do this by compiling small little programs and examining the output to determine what happened. This approach is flexible, but it is non-hermetic and necessarily requires a configure step. Hermetic build systems -- by definition -- know everything about the build environment. These rules do not have any outputs, and simply provide a way to encode the known values into build targets that can be used by the next category of rules: substitution rules.

value rules are quite flexible. They support primitive types (int, bool, string) as well as list types, and even file types (so you can read the content of a file in a dynamic action and use the content as a value later). You can also join and concatenate values that are in previously computed list values, or spread across multiple such value targets. This can be useful, for example, when embedding file content in headers.

substitution rules define mappings between variable names that might appear in the substitution file, and values that were previously encoded in the form of value rules. To explain why this distinction is needed, consider two libraries, both of whom need to detect whether ssize_t exists on your system. One library expect its configured header file to have a line of the form:

#define HAVE_SSIZE_T

while the other may expect to have a line of the form:

#define HAVE_BUILTIN_TYPE_SSIZE_T

Whether or not ssize_t exists is a universal truth, but the libraries expect to consume that information through different ways. So we need one set of rules (value rules) to encode the universally known values, and another set of rules (substitution rules) to define the library-specific mappings.

Finally, we have the cmake_configure_file rule which accepts a list of substitutions and will perform the generation.

[facebook-github-bot]

@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this in D83197772. (Because this pull request was imported automatically, there will not be any future comments.)

[zjturner]

I ran into some limitations that I want to address before this goes in but I’ll leave it open for now.

specifically: i want to change the cc test rules to be called “generic value” rules, move them out of cxx, add support for list value types, change the embedding rule yo use a dynamic action to read the content and return a GenericValueInfo, and move the concatenation / prefix / suffix logic and attributes into the list value rule so that it can work with non file values