Alternative to clobbering CMake metadata for `libabseil-tests`?

So, I'm not a fan of clobbering at all, but I don't see what alternatives to the approach in #61 would be any better:
1. make `libabseil-tests` an independent output, not based on `libabseil`
* would mean either being unable to co-install (hard blocker for using `libabseil-tests` where another dependency in the environment already run-depends on `libabseil`) or clobbering _all_ artefacts when both end up being co-installed (way more risky IMO than clobbering just the metadata)
2. package the tests in `libabseil` proper
* would mean we bring a lot of unnecessary stuff along everywhere, and also bump to MacOS 10.13 minimum
3. make `libabseil` contain the CMake metadata (and only that) for the test targets
* errors would be confusing if your build depends on a test-target (like protobuf), but you only have `libabseil` installed, because the CMake metadata would be wrong, so we'd get some variation of linker errors or files not found.
* might be an elegant solution, but this would need some very convoluted build scripts. It would be a big pain IMO to dynamically come up with the right list of [files](https://github.com/regro/libcfgraph/blob/master/artifacts/libabseil-tests/conda-forge/linux-64/libabseil-tests-20230125.2-cxx17_h59595ed_0.json#L254-L315) we'd need to delete for `libabseil`, after initially building everything with tests enabled.

I think the clobbering introduced in #61 is be the least bad trade-off, especially as it's only going to happen for a really niche build dependency (no-one should ever be run-depending on the test targets).

I ended up merging that PR to make forward progress on protobuf, but happy to implement any decision we come to here.

CC @xhochy @isuruf @hmaarrfk

_Originally posted by @h-vetinari in https://github.com/conda-forge/abseil-cpp-feedstock/issues/61#issuecomment-1546503946_