Add support for specifying --access, aligning better with default publish behavior

[saracope]

Closes #80

Changes:

• Update the --dry-run flag so it is passed to pnpm publish to get more useful feedback.
• Remove the hardcoded --access=public argument and instead allow users to pass the --access flag with public or restricted set.

Previously, running pnpm release-plan publish would force any package to publish as public, even if the access was set to restricted in the package.json.

This change better matches the default behavior of pnpm publish and allows scoped packages to avoid being switched to public accidentally.

With this change, the expected behaviors are:

1. Running publish without an --access flag will respect the publishConfig access set in package.json
2. Running publish with an --access flag will override the publishConfig access set in package.json
3. Running publish without an --access flag and no publishConfig access set in package.json
   1. if your package is scoped, it will publish with restricted access
      "By default, scoped packages are published with private visibility." [source]
   2. otherwise, it will use the default publish
      "By default npm will publish to the public registry. This can be overridden by specifying a different default registry or using a scope in the name, combined with a scope-configured registry (see package.json)." [source]

Important

Item 3 here could use extra consideration because I think it could cause a breaking change for folks who do not set the access in their package.json or publish command.

---

[wycats]

I think it makes sense for release-plan to have the same behavior as normal npm/pnpm here. That means that scoped packages that publish using release-plan would use publishConfig.access to specify that they should be published using --access publish.

This has a few upsides:

1. This communicates the package's access to other tools that might rely on default npm behavior.
2. By relying on the default behavior of pnpm, we also pick up other ways that you might have configured the access setting.
3. It is also forward-compatible with potential future changes in either npm or pnpm that further adjust how the access is configured.

The TL;DR is that this PR removes the hardcoded --access public entirely, which buys us compatibility with the standard ways of configuring the access.

---

However, this would be a breaking change, because many existing release-plan packages do not currently configure their access.

I personally think that release-plan apps should explicitly configure publishConfig.access, which would make their public access visible to other tools.

But the vast majority of existing release-plan packages are Open Source packages without an explicitly configured access, and this would break their builds. How should we deal with the breaking change? A couple of options:

1. Cut an 0.10 release, document the breaking change and migration (i.e. set "publishConfig.access": "public" in package.json or in .npmrc).
2. Attempt to determine whether the user has configured access (by reading package.json and calling pnpm config get access). If the didn't configure access, stick to the current default behavior, and instruct the user to update their package.json.

[NullVoxPopuli]

However, this would be a breaking change, because many existing release-plan packages do not currently configure their access.

as it turns out, it's only a breaking change for packages that haven't yet published any version at all, because once you publish a public scoped package, npm knows that it's public, and keeps going with that.

Relying on default behavior protects us nicely here

[NullVoxPopuli]

🙌

[NullVoxPopuli]

thank you!!!

[mansona]

Can I just say, this is a great PR 😍

It's also fantastic to take a weekend off and come back to a whole loop being closed! Great work everyone! 🎉