Add Support for cargo nextest && Fixed support for deno

[spigaz]

This is still work in progress:
https://nexte.st/book/custom-test-harnesses.html

Progress

• Added support for -h and --help w/tests
• Added support for -V and --version w/tests
• Added support for --list --format terse w/tests
• Added support for --list --format --ignored w/tests
• Add support for <test-name> --nocapture --exact w/tests
• Reinstated support for --include-ignored w/tests
• Reinstated support for --skip name w/tests
• Reinstated support for --skip=name w/tests
• Reinstated support for filter w/tests
• Solved the temporary directory conflict caused by the concurrent invocation
• Update --include-ignored to use docopt
• Update --skip name to use docopt
• Added tests to execute tests on nodejs
• Fixed support and added tests to execute tests on deno
• Add tests to execute tests on chrome
• Added tests to execute tests on firefox
• Add tests to execute tests on safari
• Add tests to execute tests on edge
• Add tests with cargo nextest invoking wasm-bindgen-test-runner
• Add feature! macro to simplify testing
• Add feature_template_runtime! to execute the specification over all the runtimes

Updated to use docopt

• It was used already in wasm-bindgen
• Not sure if you want to use something more modern, its easy to change
• Just checked its unmaintained https://github.com/docopt/docopt.rs and recommends clap or structopt, but structopt's docs state "As clap v3 is now out, and the structopt features are integrated into (almost as-is), structopt is now in maintenance mode"

Updated the macro wasm_bindgen_test

• To export and additional method to allow listing handling as required by nextext
• Not sure if it might make sense to override current export

Testing

• I wasn't sure what was the best place to put the tests in, because of the custom test runner in the cli crate, so I placed them on main tests folder.

• I used a variation of BDD that I use for many years now.
  -- Although it seems a bit more verbose, it makes writing tests a lot simpler and faster, anyone can understand them and add new ones.
  -- When something breaks its very easy to understand why.
  -- Although conter-intuitive, in practice I have found that they are a lot easier to update on refactors.

Overhead

• When used from cargo nextest the overhead is pretty real, as it has to load the runtime and the wasm into it, so it can be a lot, but it runs them in parallel, so it makes up for it on tests that take a long to execute.

Architecture:

• I would prefer to organize the code into:
  -- a folder with the CLI and environment stuff
  -- a folder with the wasm handling
  -- a folder with the runtimes

[daxpedda]

Apologies for the delay, I was on vacation, still catching up.
Planning to take a look tomorrow!

[spigaz]

That's okay!
I still have one missing piece ahead to get it working with cargo nextest, so its fine.

[spigaz]

Well its working, actually its my second version working, the fist one used locks.

But according to the the library documentation it shouldn't work (at least cross-platform):

See the tests in lib.rs for cross-platform lock behavior that may be relied upon
// Concurrent shared access is OK, but not shared and exclusive.
// Once all shared file locks are dropped, an exclusive lock may be created;
// No other access is possible once an exclusive lock is created.
// Once the exclusive lock is dropped, the second file is able to create a lock.
https://github.com/danburkert/fs2-rs/blob/master/src/lib.rs

Anyway, the overhead was as bad as I expected, as each test execution now requires the same overhead as a complete assembly, I only tested on firefox so far, about 12-13s each, thermal throttled.

But when tests take longer than the overhead, the extra cores start to payoff.

I'm having thermal throttling issues, but my speed boost might be around 3x when I have the tests configured for very heavy parameters, its a property based testing variation.

[spigaz]

I was waiting for your review, because as I do more tests, I end up finding more stuff to fix, making the review harder on you. Sorry.

I ended up fixing support for deno, not sure why, but it was for sure broken.
I added some tests and updated the github action, so now its under control.
You can cherry pick that if you want.