Rethink the questions beachball asks to aid devs in making better decisions

Today, when beachball detects changes, it prompts for patch/minor/major and asks for a description. This leads to unhealthy choices for devs who can't recite the differences between them. For pre-release (v0) packages, this becomes even more confusing and beachball gives no additional information here, pushing the burden to the developer to "just know" that the package is a pre-release and that v0s have different rules about semver resolution.

One suggestion could be something like this:

Non-prerelease questions:

What kind of change are you making to the api surface of `package`?

( ) patch: No api surface changes, only changes within the api.
( ) minor: Some backwards-compatible api surface updates or additions, or visual updates which don't impact layout space.
( ) major:  Changes which could cause compilation breaks for consumers or visual shift in UX. This may include removal of api surface or breaking changes to existing apis.

For pre-release packages:

What kind of change are you making to the api surface of `package`?
Note: This package is a pre-release, where semver rules are different. Read the descriptions carefully.

( ) patch: Some backwards-compatible api surface updates or additions, or visual updates which don't impact layout space.
( ) minor: Changes which could cause compilation breaks for consumers or visual shift in UX. This may include removal of api surface or breaking changes to existing apis.
( ) release: Release a major v1. Only choose this if you're confident no breaking changes will be needed in this package for a long time.

Start by tracing where beachball asks for patch, minor, major, and the change description. Compare the proposed non-prerelease and pre-release wording, then verify that the prompts explain the semver choices and offer the distinct v0 release option.