(feature request) [assemble-lite] support JS data providers

[mbehzad]

Currently the data for the templates used by assmeble-lite to generate html pages come from .json and .yaml|yml files.
This will allow only static data. But there are use cases for data with more dynamic nature, e.g. reading from file system for icons or font files, getting the pkg version or last commit hash, different basepaths based on env variable for the local dev build or the build for the hosted LSG, or even fetching data from the network (mainly for EDS projects where the data comes from google drive / EDS CDN). Previously a workaround for such cases were handlebar helpers. It could be argued that it is always better to keep hbs helpers conceptualy pure, only having their input from the template where they are called upon and outputting to the template output. But what they definitely won't be able to work around are async operations.

To solve this and provide easier options to create such data, in addition to .js/.yaml files, .js files can be supported.
something like:

// e-icon/demo/e-icon__data.js

module.exports = async function() {
	// gather the data

	return data;
}

A common js module which has a default export, a json or a function (because it would practically be required, a json export would always be cached and only invalidated once the file content itself has been changed. Therefor the function variation that is called and returns the current data on each watch build is more preferred.). This function can be async and get the data from wherever it makes sense.
Performance vise, in the webpack dev mode, on each build, it can even use cached values and only update in the background. and the Assemble instance would better be able to track what is changed and what needs to be re-rendered, compared to hbs helpers with dynamic output.

Currenlty all .yaml/.json files in the components folder will be used for the template data. This means any api mocks, or swagger files will also be added to assemble data. Which although unnecessary, won't create any issues. this won't be the case if all .js files are also called to get the data. What makes sense is to mark these files. "*__data.js" seems more suitable to me as it is currently the default naming in the pv-create-component for .yaml/json data files. Other option would be to make it configurable, or some other specific extension or folder names (similar to what 11ty does with *.11tydata.* files or _data folder).

The only downside compared to hbs helpers is that it wouldn't be possible to pass any parameters to it (theoretically we could pass the front matter data from the template to the data js file but that seems like a lot of complication/weirdness to me). But i think there won't be that much use cases for different data for different templates.

Packages which would need to be updated to support this:

assemble-lite: the classic and and Assmeble instance where they get/parse the data
pv-stylemark: data passed to assemble and being watched by webpack
pv-create-component: option to create a js file for the data (although i think it is still better to force user to use the static json/yaml files as much as possible to have the code more simple)
pv-scripts: default config, if we want to make this data file patterns configurable, although I would rather go for the hard-coded __data.js for now.
vscode-pv-handlebars-language-server: provide these filenames for the autosuggestion / goto definition