New NPM workflow

[jgranick]

In practice, a developer would use the new workflow like this:

1. Create "templates/html5/npm"
2. Add a package.json and any supporting files (vite, webpack, rollup, etc)
3. Add <template path="templates" /> and <config:html5 npm="true" /> to their project.xml
4. Edit package.json and wire up "lime:" scripts. For example, "lime:build" to call "vite build", "lime:test" to call "vite", or "lime:run" to call "vite preview"

The PR makes the following changes:

1. Adds a new lime display (target) --template-context command
2. Adds a new lime display (target) --template-context --json command
3. Removes old default Webpack configuration
4. Enables NPM using either -npm (as before) or <config:html5 npm="true"/> (new)
5. Initializes the NPM configuration once, then preserves between builds until lime clean
6. Moves NPM template files to targetDirectory instead of targetDirectory + "/bin"
7. Allows optional "lime:preupdate", "lime:update", "lime:prebuild", "lime:build" NPM scripts
8. Has required "lime:run" and "lime:test" commands, which replace the Lime tools behavior (after update+Haxe build)
9. Haxe output goes to targetDirectory + "/build"
10. Asset files go to targetDirectory + "/public"
11. Adds a new LIB_(NAME)_PATH template context variable, in addition to LIB_(NAME)
12. Allows Lime tools target flags which begin with two dashes
13. lime test html5 -final calls "lime:build" + "lime:run" scripts (production), rather than "lime:test" (dev server)

Example project:

https://github.com/openfl/flight

The above project does not automatically recompile Haxe sources (although it should hot reload if the Haxe sources do change), however this could still be done with a little cleverness. The "hxml" folder is still present within the NPM project context, so installing Haxe as an NPM dependency, or using a plugin, should make it possible.

I avoided making that required by default, because it breaks promises the Lime build process makes in terms of your Haxe code output, like what version of Haxe is used. The default NPM package.json in this pull request is designed to form the basis of customization by the user, rather than presuming which packages and path they would like to take, which may be the most mature path to take here.

Open to feedback

[jgranick]

After writing and considering the path of this pull request, I've made a course change and moved back to the following:

1. All output goes to html5/bin -- regardless of whether NPM mode is enabled or not. This should also allow downstream tooling to have fewer surprises
2. The default package.json now has a minimal configuration which allows lime test html5 and lime test html5 -final to behave as expected (this avoids a surprise, where lime test html5 does nothing)

I could have done this using http-server, and it would have appeared even more seamless, however I suspect it would also lead to a dead-end, of "why is this even here?"

Instead, I've made a minimal configuration which uses vite to build and serve. Vite is doing very little here, though it offers a suggestion of what could be possible.

Uncertain if Haxe NPM should be used for hot code reloading, as it breaks expectations on how Haxe sources are built (different Haxe version, features, so on)

[jgranick]

If we like some or all of this, I can also break into smaller pull requests. I can also adjust based on feedback.