feat: add separate `release` command with `artifactsRootPath ` config

Update: issue and expeted behaviou has been updated after sync with @layershifter

Current Behaviour

Currently beachball has hardcoded behavior regarding how it publishes. It can only publish assets that are created within package boundaries

Example of setup:

package-a/
  |- dist/ # here is all my transpiled/bundled/minified code ready to ship
  |- src/ # here is all my source
     |- index.ts
  |- package.json 
  |- .babelrc.json
  |- tsconfig.json
  |- package.json 

Expected Behaviour

While this default setup works in scenarios where one uses lerna or yarn workspaces, it doesn't work with scenarios where one want's to automatically generate package.json based on source of truth (code) or do some kind of post processing ( like removing all churn from package.json - devDeps, scripts etc that might be a security hazard to consumer).

Example of setup:

dist/
  |- package-a/ # npm publish needs to run from here
      |- index.min.js
      |- index.d.ts
      |- package.json
package-a/
  |- src/ # here is all my source
     |- index.ts
  |- package.json 
  |- .babelrc.json
  |- tsconfig.json

For example NX outputs all assets outside of package source and creates those under repo root dist/ directory which has multiple benefits (elaborating the benefits is out of topic for this issue).

To accommodate described behaviour, we need to be able to trigger release (npm publish, git tag and pushing git tags to origin) by separate command and be able to set different packageJsonPath from CLI or via configuration.

This can be also a completely new API , that can be more explicit/descriptive:

Workflow:

# 1. bump package.json + generate CHANGELOG.md
beachball bump

# 2. execute package build
yarn build

# 3. npm publish + tags
beachball release --artifactsRootPath="dist"

The issue names no implementation files; start by locating the existing bump and publish CLI entry points and their configuration handling. Trace how packageJsonPath and package boundaries are currently resolved, then define the separate release workflow so artifactsRootPath can target built packages and publishing includes npm release and git tags.