Make @storybook/csf-tools a peer dependency

[tmeasday]

Externalize @storybook/csf-tools which is a large dependency which will have been by installed by the user already (see this conversation: https://chromaticqa.slack.com/archives/CMMBWSJ1W/p1702342681865589).

We only use that package for metadata extraction in SB6 so we should verify this doesn't break that.

📦 Published PR as canary version: 11.0.0--canary.874.7204664733.0

✨ Test out this PR locally via:

npm install chromatic@11.0.0--canary.874.7204664733.0
# or 
yarn add chromatic@11.0.0--canary.874.7204664733.0

[shilman]

We should probably try to optimize this inside csf-tools somehow. It's meant to be a lightweight utility that anybody can use to read/modify/write CSF but it's pretty chunky.

@valentinpalkovic and i have discussed rewriting in SWC and I'm not sure whether that would help or hurt the install size.

[tmeasday]

@ghengeveld we should decide whether we want to make this change.

Upside: our package is ~1.15MB smaller (main chunk 3.79 MB -> 2.64 MB)
Downside: if the user is using SB6 & a strict package manager (like yarn pnp or pnpm), they will need an explicit dependency on @storybook/csf-tools (matching version with their other SB packages) in package.json.

I made a change to only import async so that the above issue will only affect such package manager users if they are on SB6 (where we actually use the code). We'll also need to figure out how to document this.

[ndelangen]

• Why is the big dependency a problem?
• Could we make it a seperate entrypoint and async load it that way, so it's only loaded when it's needed that way?
• Could we release a version of chromatic's CLI that only supports storybook 7 and up?

[tmeasday]

After some consideration we decided not to do this an instead reduce the size of @storybook/csf-tools if possible. Although we can almost certainly rely on the user having that package already, it's not strictly guaranteed, so relying on it is too dangerous.