CLI: Improve support of mono repositories

[valentinpalkovic]

Closes #21216
Closes #21710

What I did

Improved support for mono repositories to apply the "wrapForPnp" wrapper also in mono repository environments. Additionally, an auto migration was added.

Improved support for projects which are part of a workspace configured by yarn, npm, pnpm, lerna, turbo or rush

How to test

• Go into a project which is part of a mono repository setup or where yarn pnp is enabled.
• If the project is a yarn workspace with pnp enabled, please run yarn exec <storybook-project-folder>/code/lib/cli/bin/index.js automigrate for the automigration or yarn exec <storybook-project-folder>/code/lib/cli/bin/index.js init to initialize Storybook. Otherwise, you can ditch the yarn exec part.
• Please check whether the values for the configuration fields in main.ts are properly wrapped by the wrapForPnp or getAbsolutePath wrapper.
• Play around with the following origin scenarios:
  • a wrapForPnp function is already in place, but is not used to e.g. wrap addon values
  • test it for main.ts and main.js files.

Tested scenarios:

• init
• auto-upgrade
  • where no fields were transformed
  • where all fields were already transformed (wrap-require automigration skipped)
  • where some fields were transformed (do not introduce a new wrapper if getAbsolutePath or wrapForPnp functions are in place)
  • checked for Typescript and Javascript

Checklist

• Make sure your changes are tested (stories and/or unit, integration, or end-to-end tests)
• Make sure to add/update documentation regarding your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts
• Make sure this PR contains one of the labels below.

["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]

[yannbf]

Changes all look great! I haven't QA'd this but I plan to do it later this week! I'm curious what will happen in scenarios where people have a "base" main.js which is used in other main.js files e.g.

import baseConfig from '../../../storybook-common/main'

export default {
  ...baseConfig,
  stories: ['...']
}

[valentinpalkovic]

Changes all look great! I haven't QA'd this but I plan to do it later this week! I'm curious what will happen in scenarios where people have a "base" main.js which is used in other main.js files e.g.

What should happen? -> Nothing will happen ;) We are doing AST analysis, so we don't follow the path of their base config. They would have to apply the changes manually. There is no chance for us to figure out whether we have to run the auto migrations. An edge case we can safely ignore. It's not worth supporting it in the auto migrations.