feature: Support array of globs as testLocator

[docnoe]

It's sometimes very complicated, if not impossible to construct a glob string that matches all test files in some locations. This change makes it simpler by supporting arrays of globs.
E.g. in package.json the "testLocator" property can now look like this:

"testLocator": [
  "./@(models|routes|middleware)/**/*.test.js",
  "./config.test.js",
  "./node_modules/my-custom-module/**/*.test.js"
]

A single string is still supported, of course.

[searls]

My only concern here is that it seems to deviate from the implementation #44 would take us (which is to rely on shell expansion as the final argument). I think @cpruitt & @agent-0028 were working on that one. Maybe they care to weigh in?

This seems to shed light on a path of just splitting the module's behavior: if invoked with > 0 paths, use those. If not, look for this testLocator and use the glob package as this PR does in package.json. If neither, run the default.

[cpruitt]

Based on what we're currently working on, shell expansion will probably mean that load will end up receiving an array of files for which shell/glob expansion has already been performed. Moving globs to the shell, we can take advantage of all of the shell's expansions. In the current work in progress we still have a separate command line argument for --testLocator which is intended to function the same way as the quoted path string does now.

I'm putting some time into this this week so I'd be curious about whether there is a specific use case for needing --testLocator to be able to support an array and parse out globs apart from shell expansion the way it does now. If so, I'd like to take that feedback into account.

[searls]

Ok, @cpruitt I hereby declare you in charge of this series of related features. @docnoe I ask for your patience :)

[searls]

I believe this was implemented as part of #47, right @cpruitt?

[cpruitt]

@searls Yep, that’s correct.