Add support for multiple template engines about pota

[ThaNarie]

Update

• Implemented twing-loader as webpack loader to keep the flow as similar as the ts templates as possible.
• Added a .twig version of all default skeleton templates, the site is rendering

The twing-loader configuration is a mess though, unclear as of why (maybe partly esm, and partly no webpack 5 support?).

Issue 1 - the environment module path

Either way, the loader config requires a path to a twigEnvironment.js file (environmentModulePath), that exports an instance of TwingEnvironment.

This environment instance is used in two places:

1. inside the actual loader code – which is using require. This file should be exported as .cjs to be properly loaded.
2. inside the proceseed twig file from the loader output – which is using webpack_require, expecting a esm module.

Regarding 2) it is possible to load a .cjs file extension and use commonjs exports, but the webpack should be informed that it is indeed a commonjs file. Which means the babel-loader config should accept cjs in the regexp, and the file should be located in the src folder.
Which is something we'd rather not do, since it's more of a loader config file, and not a source file. But otherwise there is no way for webpack to correctly load and process this file (as cjs).

It seems that in this "more modern esm project setup" the twing-loader requires both a cjs and esm version of the environment file. Which is super annoying, but doable if we keep them in the package. If we would expose the loader configuration to outside the project, this would become more cumbersome.

issue 2 - exporting files into the lib folder

The location for the twigEnvironment file should probably be the muban-webpack scripts, positioned in the lib folder when published to npm.

Getting the .cjs file there alone already is an issue, and exporting the .js file (as esm) additionally makes it even more complex.

If we keep it as a .ts file there, it will always be transpiled and renamed to .js. It seems that the TypeScript 4.7 Beta allows two new extensions, .cts and .mts, outputting as the respective js extensions. However, adding an additional TS export config just for this one config file might be a bit overkill.

Maybe we should just create those file in the root of the package folder, and not use TS to transpile and copy them over?

Next steps

I wonder if it would make sense to create a standalone repro of the above issues, and see if the package owner is willing to explain or invest some time into fixing it. Otherwise we have to make some changes in our forked version. Either accepting two config paths, or do internal replacements based on convention, or include esbuild in the loader to transpile a temp cjs file from a passed esm file...

Anyhow:

• Decide if/how we want to support moving the twigEnvironment to the project level.
• Decide if/how we want to create or transpile two versions of this configuration file.
• Decide how we are going to configure the twing-loader.