feat(repo): prompt for project details in 'repo create'

What does this MR do and why?

glab repo create took every project detail from flags or defaults. Creating a project with anything other than the current directory's name meant knowing the flag names up front, and there was no way to simply be asked.

This adds the prompts from the issue, and a --yes to skip them:

$ glab repo create
Project name: my_project
Project description: something useful
Visibility: private

A flag that was passed always wins, so glab repo create --name foo --private only asks for the description. The check is Changed() rather than a comparison against the zero value, so --description "" is respected as "deliberately empty" instead of being asked again.

Closes #570 (closed)

Notes for reviewers

• --yes means "ask nothing", so it also covers the two confirmations that already existed (git init and the local project directory). It takes the same path as a non-interactive shell: flag values and their defaults.
• Private is the first visibility option. The highlighted default of a select should not be the one that publishes a repository to the whole instance.
• A path argument suppresses the name prompt. glab repo create my-project already answered that question, so it is not asked again.
• Behaviour change for interactive users: glab repo create in a terminal now asks three questions where it previously asked none. That is the point of the issue, and --yes is the way out. Non-interactive runs, scripts, and CI are unaffected.

Prior work

!2952 (closed) by @Ashutosh0x attempted this in March and was auto-closed in July as stale, without a human review. That MR built a huh form directly; this one goes through the IOStreams.Input/Select wrappers instead, per the flag and IO conventions in .gitlab/duo/mr-review-instructions.yaml, and adds test coverage.

Testing

Four tests using the ugh console harness:

• Test_projectCreateCmd_PromptsForUnsetDetails passes a path argument, so it drives the description and visibility prompts and asserts that the name comes from the argument rather than a prompt.
• Test_projectCreateCmd_PromptsForNameWhenNotGiven omits both the path argument and --name, so the name prompt itself runs, including its blank-input validation.
• Test_projectCreateCmd_DoesNotPromptForDetailsGivenAsFlags asserts the flags win.
• Test_projectCreateCmd_YesSkipsPrompts runs against a TTY with empty input, so any prompt that still fired would fail the test.

go test ./internal/commands/project/... passes, golangci-lint run reports 0 issues, and make gen-docs output is committed.