fold in the RowReplacer specialisation in preparation for adding extra forthcoming cases
fold in the RowReplacer specialisation in preparation for adding extra forthcoming cases

after the previous commit the two had become essentially the same, except for the loop in insert_row and replace_row which will immediately terminate in the SupportsReplace case; benchmarking showed no performance difference so it isn't worth maintaining two variants.

features in the pipeline will require us to switch back to the base case for certain tables, so the decision between the two cases won't always be able to be made at compile time.

willbryant/kitchen_sync,willbryant/kitchen_sync,willbryant/kitchen_sync,willbryant/kitchen_sync,willbryant/kitchen_sync,willbryant/kitchen_sync