Use source build of gflags

[jwnimmer-tri]

Edit: Original issue title was [wheel] Use host OS build of gflags.

In our regular builds, we obtain gflags from the host operating system:

setup/mac/binary_distribution/Brewfile:15:brew 'gflags'
setup/ubuntu/source_distribution/packages-jammy.txt:14:libgflags-dev
setup/ubuntu/source_distribution/packages-focal.txt:14:libgflags-dev
setup/ubuntu/binary_distribution/packages-jammy.txt:14:libgflags2.2
setup/ubuntu/binary_distribution/packages-focal.txt:14:libgflags2.2

For some reason, in the wheel builds we recompile it from sources:

drake/tools/wheel/image/dependencies/projects.cmake

Lines 72 to 77 in 8dff9ef

	# gflags
	set(gflags_version 2.2.1)
	set(gflags_url "https://github.com/gflags/gflags/archive/v${gflags_version}.tar.gz")
	set(gflags_md5 "b98e772b4490c84fc5a87681973f75d1")
	set(gflags_dlname "gflags-${gflags_version}.tar.gz")
	list(APPEND ALL_PROJECTS gflags)

None of pydrake depends on gflags, so should be no problem with needing a pic-static gflags or anything along those lines.

Using two different builds hazards possible build shear or unexpected bugs, and rebuilding gflags from source wastes time.

We should drop gflags from the wheel list of projects to rebuild, and instead just brew- or apt-install the host OS version.

(Relates tangentially to the #17231 project to unify our dependency infrastructure.)

[jwnimmer-tri]

Hmm, actually... since it's not a runtime dependency anyway, perhaps just building gflags from source (across the board, in all build configurations) would simplify everything without any downsides? I'll investigate.

[jwnimmer-tri]

I'll investigate.

Shrug, I didn't investigate. But it seems worth trying in any case.

Next action on this ticket would be to switch @gflags to a source build in drake/tools/workspace/gflags/..., and see what (if anything) fails.