Make libtool wrapper handle ar args

[keith]

When interoping with other build systems, like through rules_rust or
rules_foreign_cc, they often expect the AR env var to be set to the
literal ar command line tool. Apple currently ships an ar from the
cctools repo that doesn't have the same hermeticity flags as llvm-ar
(specifically it is lacking D). Because of this we use libtool which
supports -D. This change allows callers to not care about that
difference and pretend our wrapper is ar, and we still correctly
create archives with libtool.

[keith]

it's possible that we could just use ar instead of libtool for everything but that would be a bigger change that im not sure i want to mess with right now. current issues:

• i don't think there's a way to stop apple's ar from printing warnings about empty object files as we do with -no_warning_for_no_symbols (maybe we could solve if we still had a wrapper)
• -arch_only doesn't have an equivalent, im not sure how much of an issue that is but i'd have to look at the places in rules_apple that create universal archives
• previously ar wasn't hermetic as mentioned in the description, but as i looked for this change it seems like ar isn't hermetic, but it automatically runs ranlib which might zero out the things that the lack of -D doesn't solve, so it might end up being the same. i need to dig more to validate this

[keith]

the other question here is do we rename this wrapper. currently rules_rust uses the fact that it's named libtool to make a decision here, but now it doesn't matter anymore.

[keith]

based on my testing, since xcode 26.4 ar is actually hermetic (as long as it runs ranlib too, which it does unless disabled, and is generally expected to be run anyways). unfortunately the latest OSS dump doesn't include that version so I can't see what the new logic looks like

[keith]

i think we have to rename the binary, too many places checking that name, and there can still be toolchains that actually use libtool and so that logic can't be removed from the rules