Improve internal package testing

[jaredpalmer]

I stole the current testing strategy from nytimes/kyt several years ago and have been using it on almost all of my CLI tools. Nowadays there are probably better ways to test CLI tools (including using tools like Verdaccio to run end-to-end tests).

I want to open up discussion for improving testing and stability of tsdx.

[agilgur5]

Just copy/pasting my thoughts from #492 here so they're in the same place:

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.