feat(stark-testing): create separate stark-testing package and use it in all stark packages and starter

[christophercr]

Fixes #68
So that our unit-testing tooling is optional for the end users (they might want to use tape or what not).

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/NationalBankBelgium/stark/blob/master/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[X] Feature
[ ] Code style update (formatting, local variables)
[X] Refactoring (no functional changes, no api changes)
[X] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Unit testing is done using Webpack and including all unit-testing specific dependencies in all the packages that include unit tests.

Issue Number: #68 #84 #93

What is the new behavior?

• Unit tests are no longer performed with Webpack, karma-typescript is used instead which makes them a lot faster.
• The new stark-testing package includes all tooling needed to run unit tests in stark packages so these packages only need a dependency to stark-testing (by the relative folder path instead of a tgz package)
• The new package is included in the build process as well.

Does this PR introduce a breaking change?

[ ] Yes
[X] No

Other information

Renamed all build:stark-xxxx and clean:stark-xxxx scripts to remove the 'stark-' prefix and keep consistency with the rest of scripts.

[SuperITMan]

Why not put a peerDependency on @nbb/stark-build and use helpers directly from stark-build ?
Except if we only plan to use root(). But maybe later for e2e we will use other methods already defined stark-build/config/helpers.js.

What do you think about that ?

[christophercr]

Well, the idea is to make Stark as flexible as possible, so normally all the testing tooling is just a decision we made in Stark and should not have any impact in the final users of Stark (install our deps in their project) if they decide use another tooling.

So, we should keep this package as independent as possible, because again, Stark is really flexible and the stark-build might not be the package selected by the user to build their app...

[christophercr]

In any case, we can review this later once we have a better view on how all our packages will be used in a client app.

[dsebastien]

Ok for me

[christophercr]

Ok, I've resolved the conflicts so this PR can be merged now ;)