feat(publish): add --include-private option for testing private packages

[fahslaj]

Description

Adds an option --include-private to lerna publish. This allows packages marked as "private": true in package.json to be published. Since npm does not allow publishing packages with "private": true, lerna will strip out the property before the publish.

The option accepts a list of package names to be included in the publish. The packages provided are only published if those packages are deemed necessary to publish, as is consistent with lerna's existing publish behavior. Alternatively, a "*" can be provided, telling lerna to allow any private package to be published.

$ lerna publish from-git --include-private my-private-package my-other-private-package
$ lerna publish from-git --include-private "*"

Motivation and Context

This allows for the ability to publish packages that are currently private, but will be public in the future. This is useful for end to end testing. These packages can now be published to a locally hosted npm repository and downloaded for real in the end to end tests, all before the package is ready for publishing on the public npm repository.

Lerna's official stance on publishing private packages (and that you shouldn't do it) wouldn't change with this PR. If a package is meant to be published, then it is by definition "public", which means it should not have "private": true in package.json (as described in the npm docs). However, this strict implementation by lerna leaves no room for the specific use case outlined above - for packages that will be public, but aren't yet.

Therefore, this option is meant to be used as a workaround in CI pipelines for testing purposes, not for consistently publishing private packages to actual public repos.

Note that this PR is talking about packages with "private": true in package.json, which is different than npm's idea of scoped private packages.

How Has This Been Tested?

This has been tested manually and covered by e2e tests.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (change that has absolutely no effect on users)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[JamesHenry]

Needs manual rebase after the refactor, please ping me if anything is unclear on where it should live now