SERVER-15038 coerce correct behavior when multiple bg index builds are interrupted

Scenario: On a secondary; multiple background index builds are running on the same collection. Those builds are now yielding and the replication applier now attempts to apply a command that requires the index builds to terminate, such as a drop collection command. Such index builds' curops are flagged as killed, and then the command proceeds. The drop command asserts with BgOpInProg, which causes the replication applier to yield, wait for the index build operations to recover from yield and clean themselves up, and then runs the drop command again, expecting it to succeed this time.

When the first index build recovers from yield, it finds its cursor in the cursor cache just fine (since the drop command hasn't yet run successfully; it's yielding in the applier code). It then processes one or more documents to index. Eventually, it gets around to yielding again, at which point it notices that it has been interrupted and begins to clean itself up. Part of the cleanup code is to call dropIndex() to remove itself from the catalog. This function calls invalidateAll() on the cursor cache, which some might say is way overkill, as it invalidates all cursors in the collection, not just ones that are currently pointing at the index being dropped. The cursor invalidation includes the cursor that the second index build is using to build its index.
When the second index build recovers from yield, it doesn't find its cursor in the cache, because it has been invalidated. This causes the index build to abort in a way that the drop command was not expecting. The drop command actually does not succeed on the secondary in this case, leaving the collection existing.

The fix is, after an index build yields and regains its lock, to check for interrupt before recovering our cursor.
Merge remote-tracking branch 'upstream/v2.6' into v2.6