[ospec] feat: nicer binary with support for globs (#2141)

* feat(ospec): CLI support for file-patterns and an --ignore flag

The added dependency is only used by the node.js binary - which normally only ever installed via npm/yarn anyway.

This does not interfer with ospec proper being dependencyless.

* chore(mithril): Add glob dependency needed by the ospec binary

this is only needed while ospec is inlined in the
mithril repo. As soon as ospec is split away into a
standalone npm module, this will not be required anymore.

* refactor(ospec): Use 'match' events instead of callback

Performance should be similar, but the code looks
cleaner and easier to grok.

* Misc tweaks

ospec/README.md

@@ -290,23 +290,49 @@ _o.run()
 
 ### Running the test suite from the command-line
 
-ospec will automatically evaluate all `*.js` files in any folder named `/tests`.
-
-`o.run()` is automatically called by the cli - no need to call it in your test code.
-
-#### Create an npm script in your package:
+Create a script in your package.json:
 ```
 	"scripts": {
-		...
 		"test": "ospec",
 		...
 	}
 ```
+...and run it from the command line:
 
 ```
-	$ npm test
+$ npm test
 ```
 
+ospec will by default evaluate all `*.js` files in any sub-folder named `/tests` - ignoring files inside the `node_modules` folder.
+
+So, running ospec without arguments is thus effectively the same as:
+
+```
+ospec '**/tests/**/*.js'
+```
+
+**NOTE:** `o.run()` is automatically called by the cli - no need to call it in your test code.
+
+ospec accepts a list of file-patterns (globs) giving you full control over which files are evaluated:
+
+```
+ospec '**/tests/**/*.js' '**/*.test.js'
+```
+
+Also, if you wish to skip some files (**in addition to** those under `node_modules`) add a `--ignore` flag with a list of file-patterns to ignore, like so:
+
+```
+ospec --ignore 'folder1/**' 'folder2/**'
+```
+
+...or:
+
+```
+ospec '**/*.test.js' '**/*-test.js' --ignore 'folder1/**' 'folder2/**'
+```
+
+
+
 #### Direct use from the command line
 
 Ospec doesn't work when installed globally. Using global scripts is generally a bad idea since you can end up with different, incompatible versions of the same package installed locally and globally.