streamingccl: DeleteRange range boundaries poorly handled

**Describe the problem**

During an IMPORT rollback or other operations that issue DeleteRanges, a replication stream takes substantial time to process all of the resulting events. This is in part caused by the fact that we buffer DeleteRanges into a single SSTable and then try to AddSSTable the result. This table invariably spans range boundaries and needs to be split, often repeatedly before it can be applied.

Instead, we should use the range cache to build range-boundary respecting SSTs in the first instance.

Jira issue: CRDB-30426