Fix concurrency bug in RTargetGroupMgr

The previous logic of keeping just 2 RouteTargetTriggerLists, current
and one pending, sometimes did not work as desired.  We would start
DB::PartitionCount() TaskTriggers to process the current list and use
an atomic int to keep track of when the last TaskTrigger has finished
processing the list. The TaskTriggers would be kicked off again when
the last one is done.

The issue was that some TaskTriggers could still be running when we
detect that the last one has "finished" - the atomic would haven been
decremented by all the TaskTriggers, but they may not have returned
from the Run function.  When we try to kick the TaskTriggers again,
some would not be restarted as they are still running.

Fixed this by using DB::PartitionCount() RouteTargetTriggerLists and
adding the RouteTarget to all the lists. This approach is simpler and
and also has the advantage that all the DB partition tasks can work in
parallel i.e. there's no synchronization point where some partitions
have to wait for others to finish processing RouteTargetTriggerList.

Change-Id: Ic637bced40fcfb9ef98a24e4961a914d231ab14d
Merge "Fix concurrency bug in RTargetGroupMgr" into R1.10