Use `inds1`, `inds2` smartly in `vec_approx_equal`, or remove

If it continues to look like a major time contributor in major operations.

For data frames, we don't have to slice as much of later columns if an early column has already determined the result for a given entry to be FALSE or NA. We don't even need to slice later columns at all if the earlier entries have already determined the results for all entries. If this provides a substantial speed-up, we should compare speed vs. `vec_equal` and determine whether to use it in the `abs_tol == 0` data frame case rather than `vec_equal`.

This was the original idea behind these arguments, but was never actually implemented. These args coincidentally provided a speedup as the implementation used `vec_slice` instead of `df[,]`. If we can't actually improve performance in a real way using these args, they can be removed to simplify the interface and code.

Start by locating the implementation of vec_approx_equal and the uses of inds1 and inds2, then compare its data-frame behavior with vec_equal when abs_tol == 0. Benchmark the current slicing behavior and the proposed early-result approach; done means either a measured speed improvement that justifies the arguments or their removal from the interface and code.

Written by the indexing model from the issue text.