Do not forward ARFLAGS

[armandomontanez]

This is a partial revert of #3704. It does NOT revert logic that properly finds the hermetic archiver (binary and associated tests).

cc-rs needs full ownership of flag handling for the archiver. This is in part due to ar having very specific positional flag behaviors, and partially due to some special logic in how cc-rs constructs static libraries.

The change to enable ARFLAGS was causing many toolchains that pass flags to the static archiver to error out due to conflicting expectations for flag handling. Example bad ar invocation, where cq is treated as the destination archive instead of the ar tool mode:

  ar rcsD cq dest.a src1.o src2.o

This drops forwarding of ARFLAGS to fix the common case.

[armandomontanez]

There's a world where we support forwarding ARFLAGS that makes sense in some specific edge cases, but it requires changes to cc-rs so the flag ordering makes some sense. Right now, cc-rs appends all of its own flags after ARFLAGS, while (according to this) it should be ordered something like: ar [operation/modifiers as prescribed by rs-cc] [ARFLAGS] out.a src1.o src2.o [...]

Even more complex handling is needed to support user-passed flags that update the operation/modifiers. But that would belong in cc-rs anyways.

Thanks to @dzbarsky for flagging this breakage.