Add new plugin for conditional update that makes mutation available

**Is your feature request related to a problem? Please describe.**

Conditional updates allow atomically inspecting a row in a tablet server before making an update. Currently this inspection can be done via checking that columns have exact values. Optionally an iterator can be run as part of the check to perform more complex analysis. When using iterators for more complex analysis the server side iterator code can inspect the current row data, however it does not know what updates are attempting to be made to the row.

When using conditional updates for the accumulo metadata table in 4.0 the following pattern has emerged.

* Create a custom iterator that does complex server side checks as part of a conditional mutation.
* The iterator needs to know information about what updates are being made, so this information is encoded for the iterator AND its encoded as updates for the mutation.

In the above situation encoding the information twice is error prone and a waste of time for the developer and the runtime code. For the case of accumulo metadata updates that add a compaction to a tablet metadata row it currently does something like the following.

1. Encode the files we want to compact as options for an iterator that does a server side check to ensure things like those files are not currently compacting, those files exists in the tablet, etc
2. Encode the files we want to compact as a update on the mutation that will be applied if the conditions pass.

This is an example of the duplicate encoding that is being done.

**Describe the solution you'd like**

A new server side plugin that can be executed as part of a conditional update that has access to at least the following two things.

1. An iterator over the row being updated
2. The mutation that will be applied if the all the conditions on the conditional mutation pass.

```java
interface ConditionalCheck {
boolean canUpdate(rowIterator, mutation);
}
```

This new ConditionalCheck could specified to run for a conditional mutation. It would have access to the current row data and the updates that are being attempted for the row. This would avoid the duplicate enoding issue.

Start by reading the conditional-update and server-side iterator APIs described in the issue, then trace how a conditional mutation reaches the tablet server. Define the ConditionalCheck contract around access to the row iterator and pending mutation, and consider how configuration and execution should work without duplicate encoding; done means the design supports the stated metadata-table use case.

Written by the indexing model from the issue text.