Investigate cbbackupmgr backwards merging

When performing a merge with cbbackupmgr we move sequentially through the backups in the repository in chronological order aggregating the backups into a single merged backup. Doing so in this fashion means that we may be writing mutations for keys multiple times before we complete the merge. We could improve the efficiency of the process by going through the backups in reverse order only adding keys that do not exist in the merged backup to the merged backup (determining if a key has already been merge may well be expensive and might mean this is not an effective way of merging data).

This way of merging will have several added side effects:
1) It will mean Rift data stores are automatically compacted (the data will be written sequentially leaving no dead space).
2) It will be far cheaper (money and time) to merge backups stored in AWS S3 using this method.