In accordance with Google's [Foundational C++ Support
matrix](https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md),
and given other Google projects have moved to adopt C++17 as a minimum
or default
([protobuf](protocolbuffers/protobuf@fe53593),
[rules_cc](https://github.com/search?q=repo%3Abazelbuild%2Frules_cc+%22-std%22&type=code)),
I'd like us to consider bumping this version in apple_support as well.

This constitutes a breaking change. It uses the change made in #219 as a
reference.

Changes based on
bazelbuild/rules_apple@0410c02

Fixes past
bazelbuild/bazel@4f40b7f

This way we can delete the one in bazel itself

This makes sure we don't break our libtool behavior to hash files if
there are duplicate basenames

This does nothing except when 2 versions are available on CI but
produces a warning in buildkite when the version is invalid

Interestingly today even non-duplicate names are symlinked and hashed.
I think we should probably change this just for clarities sake but at
least this encodes today's behavior

bazelbuild/bazel#25682

There are 2 separate codepaths for linkmaps, `--objc_generate_linkmap`
enables the `linkmap_exec_path` variable, and just passing
`--features=generate_linkmap` enables linkmap outputs, without any other
variables.

This combines libtool.sh.tpl, libtool_check_unique.cc, xcrunwrapper.sh,
and make_hashed_objlist.py into a single C++ driver.

This sidesteps issues with our toolchain tools having to discover
each other, and reduces some duplication in this setup.

Now that we're building the tools used in the toolchain as normal rules,
there's really no need for them to be part of the toolchain setup. This
is more understandable in general since it removes a layer of
indirection.