Investigate potential improvements to `Key.equals()`

It appears that improvements could be made to `Key.equals()`. From [the original jira ticket](https://issues.apache.org/jira/browse/ACCUMULO-4468) regarding this idea:

> In the Key.equals(Key, PartialKey) overload, the current method compares starting at the beginning of the key, and works its way toward the end. This functions correctly, of course, but one of the typical uses of this method is to compare adjacent rows to break them into larger chunks. For example, accumulo.core.iterators.Combiner repeatedly calls this method with subsequent pairs of keys.
>
> I have a patch which reverses the comparison order. That is, if the method is called with ROW_COLFAM_COLQUAL_COLVIS, it will compare visibility, cq, cf, and finally row. This (marginally) improves the speed of comparisons in the relatively common case where only the last part is changing, with less complex code.

I'm not sure why the changes proposed in the jira ticket were never merged, but this idea resurfaced when `Key.equals()` was identified in #1099. At first, I considered including the improvements of `Key.equals()` as part of the PR for #1099, but I don't think that this sort of improvement will make much, if any, difference towards the goal of #1099 so creating a separate ticket/PR seemed like the best option.

Start at the Key.equals(Key, PartialKey) overload and accumulo.core.iterators.Combiner; compare the Jira proposal to the current comparison order, especially for adjacent keys. Done means the comparison remains correct for the supported PartialKey cases and any performance improvement is demonstrated.

Written by the indexing model from the issue text.