Support automated storybook population via MAGIC

[transitive-bullshit]

This PR adds the following steps in order to aggregate the story metadata server-side during our Docz plugin hooks.

1. added an async plugin hook to docz since they were all previously sync plugin.setConfigPromise
2. using @storybook/react/standalone to build a pared down version of the real storybook frontend (with our shim aliased)
3. loading that minimal frontend into puppeteer and capturing the resulting storybook metadata => serverside via puppeteer's magic
4. create one mdx file per story type
5. add these mdx files to docz's list of mdx files via a new hook plugin.modifyFiles

Note that before this PR can be merged, it is dependent on two other PRs:

PR 1) a simple bugfix for storybook that fixes a bug where the standalone build Promise is resolved before it's actually completed

PR 2) a feature for docz that adds two new plugin hooks: plugin.setConfigPromise (an async version of the existing plugin.setConfig) and plugin.modifyFiles (which allows us to edit the list of files Docz has aggregated before Docz starts processing them)

Note that I have a fully automated working version of this locally including locally linked versions of @storybook/core and docz-core.

In the image below, the Manual Button menu item was added via a manual mdx file, whereas the Button Stories menu item was added automatically by MAGIC!

[natergj]

What level of logging should we be shooting for? This one looks like more of a debug log?

[transitive-bullshit]

Good call; we should remove most of this debugging stuff before we proceed too far w/ this module.

Looks like docz uses signale for its logging and we could follow suit with some optional verbose logging if we wanted.

[natergj]

This looks great @transitive-bullshit! If I'm reading correctly, it looks like it would be rather trivial to permanently write the MDX files for a full migration to DocZ with a simple update the the file path where the mdx file is written. Does the storybook data include information on file path of original story files?

[transitive-bullshit]

it looks like it would be rather trivial to permanently write the MDX files for a full migration to DocZ with a simple update the the file path where the mdx file is written. Does the storybook data include information on file path of original story files?

Yes and no. We're actually permanently writing the mdx files to .docz/storybook currently. Storybook definitely gives us file path info, so if we wanted we could write those mdx files next to their corresponding story js files. The issue is that there's not much the user gains from this since our mdx files use <Story kind={...} name={...} /> which requires our docz plugin and all the original stories to still exist. If our mdx files could contain the actual rendering of those stories instead of just a proxy reference to them, then we'd be on a better path towards removing the original storybook files and allowing the user to remove our plugin as well, but that's a much harder goal to reach considering the storybook source files can contain / import any JS.

[transitive-bullshit]

this should probably be separated into a separate template file that's overridable by the user.

[transitive-bullshit]

Closing in favor of #13