(test): use ts-node for tests for better testing DX

[agilgur5]

• personally, I often forget to yarn build before yarn test and that
  means I'm testing stale changes
  • ts-node is one of the easiest ways to ensure the code isn't stale
    • but it comes at a big performance penalty, tests are about 1.5x
      slower, which is much longer than the additional time for
      yarn build

So I think the perf penalty here makes this a no-go, but figured I'd PR for posterity. See #493 as a somewhat similar alternative.

This was something I mentioned in #381 (comment) but never got a response on 😐 😐 . Figured I might as well try and see what happens.

---

Related to #289.
Would like to be able to support jest --watch for internal tests, but I believe that would require programmatic access to the CLI engine, which we don't currently have. #407 actually goes a long way toward this; it wouldn't be much work on top of it to expose the CLI actions as functions and then import those for internal tests.
Just importing functions and having them in-memory should be a perf improvement over the current re-running of CLI multiple times, and jest --watchs incremental testing should be a significant improvement.
Programmatic access and imports should also make it easier to get code coverage for TSDX, which is certainly lacking in some areas.

Could then leave shelljs stuff as integration tests (which are slower) which don't need to run locally for every change, but should continue running on CI.

A separate test perf improvement I was thinking of was having the temporary stage-build (and stage-lint) directory use a tmpfs like a RAMDisk or something, which should speed up the disk I/O considerably as the files be in-memory. Not sure how cross-platform this might be for the test matrix (and Windows contributors), but still have to investigate libraries for that.

[agilgur5]

Self-closing due to aforementioned perf issues. See #493 as a somewhat similar alternative. Test perf comments still relevant here.