CDK-347. Implement DatasetTarget#handleExisting and WriteMode support.

I don't think I agree that views should be treated very differently. Views are a general way to restrict reads and writes, which is what we want here. An application wants to write to a view only if there isn't already data there, which is exactly what an any-record existence check would provide. Plus, it does that in a partition agnostic way that can be used for both HBase and HDFS.

Ben makes a good point about what currently happens, but I think the use case of preventing race conditions is outside the scope here. I do think that those points mean that we shouldn't take directory existence as any kind of signal, because we clearly wouldn't create all potential directories to signal that a job is currently running, which is what we ran into with the signal work. But again, deconflicting concurrently running jobs is not the goal of this feature, it is how existing data should be treated.

If I want to write version N of my dataset, or overwrite version N of my dataset, then does it matter whether I've partitioned it first by version for that to happen? That doesn't have much meaning in HBase, and it shouldn't matter if we organize data by other partition fields first for HDFS. What matters is that the semantics are to check to see if any data exists (which we can definitively satisfy) and take an action accordingly. And we can do that here.

If there is at least one record, then . . .
* DEFAULT should abort
* OVERWRITE should try to deleteAll and abort if it can't be done (note this isn't a problem in HBase)
* CHECKPOINT should use the ModifiedAccessor or overwrite
* And APPEND writes the data no matter what is there

I think that makes reasonable sense. We just can't use directory existence for distributed coordination, but that coordination task aligns better to the isReady / signalReady work. A similar solution would work better than combining coordination with the write mode because the write mode fails jobs.