From max.hirschhorn@mongodb.com in SERVER-101297

I would like to propose the Dev Prod Correctness team undoes the changes from 774d062 originally made as part of SERVER-90498. The changes should be reconsidered with the following details kept in mind:

1. It isn't practical to run multiple, arbitrary JavaScript tests within the same mongo shell process because the tests may depend on global, in-memory client state which now becomes shared. JavaScript tests run under separate mongo processes to provide isolation.
2. Moreover, the mongo shell doesn't yet offer a mode where it'll run all the specified JavaScript files if an earlier one has an uncaught exception. This behavior is incompatible with resmoke's --continueOnFailure mode which is enabled nearly everywhere in Evergreen.
3. Any speedup benefit from sharing the same mongo shell process across multiple tests must be re-evaluated now that statically-linked mongo shell binaries are used (SERVER-94042, SERVER-90484) and offer faster process startup times.
4. Grouping multiple test files need not to be a first class concept of the TestQueue. test_kind: parallel_fsm_workload_test and its _MultiJSTestSelector was already prior art for running multiple JavaScript tests within a single mongo shell process. The FSM workloads are specified in a TestData variable due to interactions with how the concurrency framework spawns FSM worker threads. However, a new resmoke test kind could instead be written for grouping multiple JavaScript tests and specifying them directly as positional arguments to the mongo shell process (i.e. filename singular to filenames plural change in mongo_shell_program() is ok). Controlling this behavior through the resmoke test kind is less invasive and fits better into the existing customization points resmoke offers. It also enables a way to gradually change existing resmoke YAML suite files which do test_kind: js_test today after they have been vetted to not depend on global, in-memory client state.