(feature request) [assemble-lite, pv-stylemark] support auto creation of component page variations

[mbehzad]

Currently asseble-lite will generate for each .hbs file, one html file. There are use cases where a component has various variations. e.g. dark/light, rtl/ltr, center-aligned/start-aligned .... To showcase all these variation, usually in the demo hbs file the component partial is called multiple times (directly or by iterating over some data).
This is definitely helpful to see all the variation at a glance, but this is not possible when e.g. the component can only be shown once on a page because it is sticky, it is an overlay, .... or the variations are created by setting specific attributes on the page (e.g. dir) or even using different templates (multi tenant websites).
To prevent the need of creating the demo template file multiple of times, a specific front matter property (e.g. variations or pages or outputs ...) can be introduced. Something like:

---
# demo/foo.hbs

layout: default

pages:
  default: {}	
  dark:
    darkMode: true
  rtl: 
    layout: other-layout
    dir: rtl
    pages: 
      light: {}
      dark:
        darkMode: true
---

assemble-lite would then automatically create foo.html, foo--dark.html, foo--rtl--light.html and foo--rtl--dark.html by using the front matter data for each page.
lsg markdown file would look something like:

```html examples ./demo/foo*.html
```

and pv-stlyemark then needs to find all these files and e.g. group them in a tab navigation / accordion.

This still would mean that if really all combinations are needed, then those need to be listed in the front matter manually, (e.g. dark-rtl-centered:, dark-ltr-centered:, dark-rtl-start: ... ). To make this easier, we could:

1. allow referencing other data files. e.g. pages: foo-pages__data and the foo-pages__data.yaml has all these options in it (and incase we allow js data files ((feature request) [assemble-lite] support JS data providers #235) then this can be achieved with some js nested loops.
   We could use gray-matter for parsing the front matter instead of yaml-front-matter which in addition to yaml, it also allows js (or even for custom parsers). where we could write the js that creates these variation from a for loop. (not sure if it is worth it or it will introduce a lot of complexity)

---js
const pages = {};
for (...) {
  for (...) {
    for (...) {}
  }
}
return {
  layout: "default",
  pages,
};
--- 

And even stylemark could provide toggle buttons to combine and switch between these options (dark, rtl, ...) in that case something like this (more similar to storybook's Controls/Args) might make more sense: (styleguide examples are configured via a named yaml fenced code block)

# foo.md

```html example1 ./demo/foo--[param1]--[param2].html
```

```yaml example1
  parameters:
    param1:
      description: "..."
      type: SELECT
      options:
        - name: right-to-left
	   value: rtl
	- name: left-to-right
	   value: ltr
    param2:
      type: TOGGLE
```

Stylemark generates the UI to choose between these options, and on each user selection it will use the values and fill the iframes parameterised html url with: e.g. ./demo/foo--rtl--on.html

These can be implemented independently. or in steps.
E.g. assemble creating variation is helpfull even if the developer has to list them in the markdown file individually. Or when it is not used for stlyguide but automatic testing.
Or the stylemark parameetr options can be used without the assemble pages options:

e.g.

```html example1 [variation].html
```

```yaml example1
  parameters:
    variation:
      type: SELECT
      options:
        - name: standalone
	   value: "./foo"
	- name: in-teaser
	   value: ../teaser-comp/teaser-template 
```