update karma to v6 and webpack to v5 and make corresponding updates to test configs

[peaBerberian]

After multiple try and re-try, this PR allows to switch to webpack 5 - which among other things allow to have a much more reduced file size for our default builds in dist (488199 bytes for the minified version with webpack 4 vs 472703 with webpack 5. Non minified is also reduced but much less).

It also updates other dependencies that have be held back due to that, like karma to v6.
The biggest issue I had here, was with the karma-webpack dependency, which didn't seem to work with either karma 6 or webpack 5.

Because karma-webpack is only a minor dependency used for tests and because of encouraging feedbacks, I decided to rely on the pre-release "alpha.5" release of that version, released more than a month ago.
Everything seems to work with that version.

I also chose to remove tests/integration/index.js, which required all integration tests files, in profit of using the karma configuration file for that, at it seems to be the idiomatic way to do it.

[devoto13]

I also chose to remove tests/integration/index.js, which required all integration tests files, in profit of using the karma configuration file for that, at it seems to be the idiomatic way to do it.

Just a passerby comment, but IIRC there is a significant logic behind the original implementation. With the former implementation, the Webpack will produce a single bundle with all tests and their dependencies, but with the updated code, the Webpack will produce a bundle with all dependencies for each test file (i.e. a lot of bundles). Depending on the usage this may or may not be a performance problem.

[peaBerberian]

Hi @devoto13,

Thanks for the tip.
It makes sense but I don't see it as a problem right now.

I prefer reducing the complexity of the testing setup for the moment for future developpers' / future me's sake than perhaps avoiding hypothetical performance issues - as we've not encountered any sensible one for now.
Because we're only speaking about dev-facing code, I don't see it as risky to merge that for now, we could always rollback at any time if that becomes a pain point.