[MVP]: Documentation as dynamic dev server

[nothingismagick]

Please note, this is not talking about the static docs available at the gh-pages branch.

Use unit-tested quasar for run-time ENV parsing to create dynamic documentation and pass it through storybook.

ZERO STATE
If you haven't configured your quasar app to use testing by adding the "test mode" during init or with quasar mode --add test, then this server does not exist.

BAD BOOT STATE
If the documentation isn't working, neither is your setup. The viewer of this "red page of fail" will see debugging suggestions and a wizard to help repair or update the system. This is the <noquasar> version of the live docs as localhost:9090/index.html

WIZARD BOOT STATE
@quasar/testing-base can be detected and this server started successfully. This is the default state if the test mode is initialised with only the @quasar/testing-base and no harnesses. The user is presented with a list of steps to be carried out in order to progress to the next phase. This wizard process will be a live monitor to the state of the set up your system - and should be throttled so that the user actually sees what is being installed.

ALIVE STATE
Testing is installed and functional for the highlighted icons below. In this case, it is Jest, Mocha Webpack, NVY, Chai, Cypress, Snyk - and of course Babel (but it seems i forgot to make the icon).

Background
This may seem complex, but technically it is a really great way to navigate the documents and view the myriad of reports - because the dynamic documentation of the "mode test" is actually a development server hosted locally within the scope of quasar-cli by the developer. It is built by each component of @quasar/testing that is currently active, and each test harness has a default "manual boot" process that is a "setup wizard", which has stages of installation that can only be triggered by the components being configured as described within the html-rendered and served docs - all within a quasar app. (Whether we actually turn this into an Electron app is something else entirely, but not out of the question for future work. Indeed, depending on adoption, this might even be an alternative way to debug and manage an entire installation of quasar.)

Here are some needs:

•  be an example of best practice "Quasar in use"
• be delivered as a module that hooks into current configs and creates a unique local-dev "storybook"
• use actual module data based on current setup
• have animated tabs in header
• left-panel: usage documentation for currently active unit-test harnesses
•  right-panel: config file display / editor
•  main-pane: tab-sensitive web reporter (lcov, cypress vids, lighthouse)
  key:value input fields for important files
  textArea for javascript
• include a license navigator (would be possible through an "extra")
• act as the browser for the reports from the test runners
• the icons available in the `@quasar/test/packages/base/lib/icons/${h.name}.png`

Just a sketch:

  <q-tabs v-for"h in harnesses">
    <q-tab :v-class="h.active ? "opaque" : "notOpaque" :avatar="h.name" :disable="!hactive">
  </q>
<script>
 export: {
   data () {
     return {
        harnesses: [
          {name:'jest',active:true},
          {name:'ava',active:false},
          {name:'mocha-webpack',active:true},
          {name:'tap',active:false}
// ( ... appium,chai,cypress,import-cost, istanbul, jest,karma,lighthouse,nightwatch,sinon, snyk,spectron,tap,testcafe )
       ]
     }
   }
}
</script>
<style>
.opaque {opacity:1}
.notOpaque {opacity:0.1}
</style>
    H.chroma(()=>{h.active ? harness.icon.display(color) : harness.icon.display(mono)})