make fsm workloads that extend kill_rooted_or.js more robust in the sharded concurrency suites, or blacklist them

The kill_rooted_or.js workload has a stage that issues createIndexes and dropIndexes, and since the workload uses 10 threads, this means a createIndexes can max out its CannotImplicitlyCreateCollection retry attempts, which causes the workload to fail.

(Each createIndexes attempt creates the collection; this failure happens when the collection keeps getting dropped in between mongos retrying the createIndexes).

After speaking with Dave Storch, assigning to Query to see if they would like to work to make the tests more robust to sharding, or to blacklist the tests from the sharded concurrency suites because of limitations around running concurrent catalog operations in sharding.