GH-49369: [C++][R] Deal with validating libtool again

[jonkeane]

Rationale for this change

Deal with bespoke frameworks on CRAN machines, ensure we can detect Apple-provided libtool as opposed to GNU libtool. Modernize cmake.

What changes are included in this PR?

Use VALIDATOR to validate libtool, a slightly more flexible regex

Are these changes tested?

Yes

Are there any user-facing changes?

No, well just one.

• GitHub Issue: [C++][R] More robust libtool checking #49369

[jonkeane]

@github-actions crossbow submit test-r-install-local

[github-actions]

Revision: b6fa4e7

Submitted crossbow builds: ursacomputing/crossbow @ actions-dd37c5e22c

Task	Status
test-r-install-local

[jonkeane]

@github-actions crossbow submit test-r-install-local

[github-actions]

Revision: dcc373d

Submitted crossbow builds: ursacomputing/crossbow @ actions-cb360883d6

Task	Status
test-r-install-local

[jonkeane]

The failures are either on main (macos 14) or transient (ubuntu gcc)

[raulcd]

Thanks @jonkeane ! Just so I understand for the future if this or something similar happens again. Was the problem with GNU libtool found on CI? Where?

[jonkeane]

This is something that showed up on CRAN: the red M1Mac on https://cran.r-project.org/web/checks/check_results_arrow.html.

-- CMAKE_CXX_FLAGS_RELEASE: -O3 -DNDEBUG -O2 
CMake Error at cmake_modules/BuildUtils.cmake:114 (message):
  libtool found appears not to be Apple's libtool: /usr/bin/libtool

And then separately I also received this from one of the CRAN maintainers:

/usr/bin/libtool -V
Apple Inc. version cctools_ld-1266.5

The whole reason for this detection issue is because some CRAN machines had GNU libtool (an entirely different tool higher on their path than the apple-provided libtool that does the linking we want/need see #40259). So we sniffed for a string that could tell the difference. I'm not sure why on this machine (suddenly! nothing in our code here has changed since 2024...) the version string is slightly different, but this new regex is a bit more flexible.

We test this in crossbow jobs installing macos locally https://github.com/ursacomputing/crossbow/actions/runs/22282130627/job/64454329380#step:9:790 which we setup to use GNU libtool specially: https://github.com/ursacomputing/crossbow/actions/runs/22282130627/job/64454329380#step:6:2 though that runner has the standard (apple) libtool version string that we detect just fine with our stricter regex.

I am also going to add a print if I can to the cmake to also print out the version string we get when it errors so that we didn't need one of the CRAN maintainers to send us the string.