defrag: eliminate persistent pointers

[JimB123]

This update addresses several issues in defrag:

1. A "stage" is passed a "target". For the main dictionary and expires, we were passing in a kvstore*. However, on flushall or swapdb, the pointer may change. It's safer and more stable to use an index for the DB (a DBID). Then if the pointer changes, we can detect the change, and simply abort the stage. (If there's still fragmentation to deal with, we'll pick it up again on the next cycle.)
2. We always start a new stage on a new defrag cycle. This gives the new stage time to run, and prevents latency issues for certain stages which don't operate incrementally. However, often several stages will require almost no work, and this will leave a chunk of our CPU allotment unused. This is mainly an issue in starvation situations (like AOF loading or LUA script) - where defrag is running infrequently, with a large duty-cycle. This change allows a new stage to be initiated if we still have a standard duty-cycle remaining. (This can happen during starvation situations where the planned duty cycle is larger than the standard cycle. Most likely this isn't a concern for real scenarios, but it was observed in testing.)
3. Minor comment correction in server.h

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.90%. Comparing base (0c8ad5c) to head (0ed833b).
Report is 1 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1430      +/-   ##
============================================
+ Coverage     70.76%   70.90%   +0.13%     
============================================
  Files           119      119              
  Lines         64618    64638      +20     
============================================
+ Hits          45728    45831     +103     
+ Misses        18890    18807      -83     

Files with missing lines	Coverage Δ
src/defrag.c	89.72% <100.00%> (-0.96%)	⬇️
src/server.h	100.00% <ø> (ø)

... and 17 files with indirect coverage changes