[officialasishkumar]

What this PR does / why we need it:

kctrl package repository release always asks for the repository name and the registry URL, which makes it awkward to use in CI. This adds two flags:

kctrl package repository release --version 1.0.0 \
  --name my-repo.example.com \
  --registry-url registry.example.com/my-repo

• A value given through a flag takes precedence over pkgrepo-build.yml and skips its prompt. The value is still saved to pkgrepo-build.yml, as a prompt answer is.
• A value not given is still asked for, so existing interactive use does not change. --yes still accepts the defaults for anything left out.
• An empty registry URL now fails straight away with expected registry URL to be specified (hint: use --registry-url flag). Previously --yes with no URL wrote a pkgrepo-build.yml with no image, then failed in imgpkg on an image reference of :<tag>.

The prompts moved into configureBasicInformation, so that this logic can be unit tested without kbld or imgpkg.

Which issue(s) this PR fixes:

Fixes #1276

Does this PR introduce a user-facing change?

kctrl package repository release has new --name and --registry-url flags, so it can run without prompts. An empty registry URL now fails early with a clear error.

Additional Notes for your reviewer:

The issue also suggested the short forms -n and -u. I left them out because -n means namespace across the other kctrl commands. They are easy to add if you would prefer them.

Testing:

• New unit tests in release_test.go cover flags only, prompts only, a mix of the two, and the empty registry URL.
• New e2e test TestPackageRepositoryReleaseNonInteractively runs with no --yes and no stdin, so any prompt would fail it. It passes against a local registry:2 with real kbld and imgpkg, and fails on a binary without this change.
• By hand with the built binary: answering the prompts on stdin, only --registry-url with --yes, flags overriding an existing pkgrepo-build.yml, and a blank registry answer.

Not run: TestPackageRepositoryReleaseInteractively, because it needs a cluster and I did not have one available. I checked the same prompt flow by hand as listed above.

Review Checklist:

• Follows the developer guidelines
• Relevant tests are added or updated
• Relevant docs in this repo added or updated (not applicable)
• Relevant carvel.dev docs added or updated in a separate PR and there's
  a link to that PR (not done; the new flags appear in --help)
• Code is at least as readable and maintainable as it was before this
  change

Additional documentation e.g., Proposal, usage docs, etc.: