setup.py: setuptools fallback does not link abseil when building against static libre2.a

Summary

When building google-re2 from source using the setuptools fallback path (i.e. without Bazel / outside of GitHub Actions), the resulting _re2.so extension has unresolved abseil symbols. The wheel builds successfully (shared library builds allow undefined symbols by default), but crashes at import time:

>>> import re2
ImportError: /path/to/re2/_re2.cpython-312-x86_64-linux-gnu.so:
  undefined symbol: _ZN4absl12lts_2025051218container_internal19GetRefForEmptyClassERNS1_12CommonFieldsE

Root cause

setup.py hardcodes libraries=['re2'] in the Extension definition. This works when linking against a shared libre2.so (the dynamic linker resolves the abseil dependency chain at runtime), but when libre2.a is the only available library (static build via CMake with -DBUILD_SHARED_LIBS=OFF), the linker never sees the abseil archives that libre2.a depends on.

Reproduction

1. Build re2 and abseil-cpp from source as static libraries via CMake
2. Install them to a prefix
3. Build google-re2 from the sdist using pip install --no-binary :all: google-re2 with CXXFLAGS=-I<prefix>/include and LDFLAGS=-L<prefix>/lib
4. Attempt import re2

Suggested fix

Use pkg-config --libs --static re2 to discover re2's transitive dependencies (abseil) when building from source, falling back to the current libraries=['re2'] when pkg-config is unavailable. The CMake install of re2 already produces re2.pc with Requires: absl_..., so pkg-config can resolve the full dependency chain.

This has no effect on the Bazel build path (GitHub Actions), and is backward-compatible: when pkg-config is not installed or re2.pc is absent, the behaviour is unchanged.

Context

We encountered this while building wheels for architectures where Bazel is not available (s390x, ppc64le), using CMake + setuptools as a fallback.