formula: Cyan4973/xxHash

[MeteorsLiu]

Summary

• Add the Cyan4973/xxHash LLAR Formula with exact upstream tags v0.8.0 through v0.8.3.
• Preserve Conan Center defaults and material options: shared=OFF, fPIC=ON, utility=ON.
• Apply the pinned v0.8.1 Conan patches and CMake policy workaround boundaries, preserve upstream CMake outputs, and publish relocatable libxxhash.pc metadata.
• Declare no dependencies; restrict the validated matrix to Linux or Darwin on amd64 or arm64.

Validation

• llar test --verbose ./Cyan4973/xxHash@v0.8.0
• llar test --verbose ./Cyan4973/xxHash@v0.8.1
• llar test --verbose ./Cyan4973/xxHash@v0.8.2
• llar test --verbose ./Cyan4973/xxHash@v0.8.3
• llar test --verbose ./Cyan4973/xxHash
• Explicit darwin-arm64 matrices for shared/fPIC/utility output changes
• Repeated default and utility-off matrices for cache-hit consumer tests
• v0.7.4 rejected because it precedes the first Formula threshold

Closes #244

[fennoai]

The version-specific build recipes, patches, pkg-config metadata, selection floor, default tag, Linux shared/utility matrices, and cache-hit consumer path were reviewed against the linked Conan snapshot and LLAR commit 9c062aa5c4b1724bfd30cb72f7e0bda136f9c078. The Linux formula behavior passed focused validation, but the change currently conflicts with the repository's changed-module test gate and the pre-0.8.3 recipes omit the Darwin shared-library relocation policy retained by Conan.

[fennoai]

[P1] Avoid changing multiple Formula directories in one PR

Adding this second threshold (together with v0.8.2 and v0.8.3) makes the repository's find_changed_modules.gsh collect four Formula directories for Cyan4973/xxHash; that script explicitly panics whenever a module changes more than one directory because CI can test only one fromVer range. Consequently the required Find changed modules job cannot produce a test matrix for this diff. Please either land the thresholds in sequential PRs or first extend the validation workflow so every changed range is exercised.

[fennoai]

[P1] Preserve CMP0042 for pre-0.8.3 shared Darwin builds

For v0.8.0 through v0.8.2, upstream declares CMake 2.8.12, so under CMake 3.x CMP0042 remains OLD; CMAKE_POLICY_VERSION_MINIMUM is ignored there (the focused build emits the unused-variable warning). With shared=ON on Darwin this disables the @rpath install name and embeds the build machine's absolute install prefix in the dylib. LLAR archives that output and restores it under another user's workspace, so cached/shared consumers can no longer load the library. The pinned Conan recipe sets CMAKE_POLICY_DEFAULT_CMP0042=NEW for this reason; add that definition to the v0.8.0, v0.8.1, and v0.8.2 recipes (v0.8.3's CMake 3.10 minimum already selects NEW behavior).