CLI: Versioned installation of monorepo packages

[ndelangen]

Closes #25501
Works on #25293

What I did

• Change the mechanism for picking the version to install for packages when adding packages via the package-manager. When a package is in the monorepo, a different heuristic is used. The version in versions.ts is used, and added, unless that version happens to be the latest version, in which case, no modifier is added.
• The welcome message to sb init has been changed to be more noticeable, as it can now contain a warning to the user, that they are running an old version of the CLI. (The CLI will still proceed to run the actual init!)
• It will also print a message when the user is running a prerelease version (not latest).

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

1. Create a project which storybook can init on
2. run npx storybook@{{version}} init
3. The expected outcome it that that exact version is used to init, and the project's package.json will contain the exact versions of storybook packages that was used.
4. If the listed version is exactly latest on the npm registry, the project's package.json will contain the ^-prefixed versions of storybook packages that was used.

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for 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:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

[JReinhold]

Looks good!

[socket-security]

Removed dependencies detected. Learn more about Socket for GitHub ↗︎

🚮 Removed packages: [email protected]

[JReinhold]

An alternative to the warning would be to throw an error, that could be bypassed with a --force flag if the user really intended to init with an older version. This approach makes sense if we think that:

1. Users that run npx storybook init without the version specifier are the same users that ignore warnings. This is bad because that is the exact use case for the warning
2. Intentionally initializing an older version is an edge case, where it's okay to require additional flags like --foce.

The downside of this approach is that we might need to adjust our CI/tasks to add this --force flag in any places where it's needed. I can't think of any such place right now, but I wouldn't be surprised if there was one.

I'm leaning slightly towards this alternative approach, but it's not a strong feeling.