Both SurveyAsk and SurveyAskOne methods now share the same sets of stubs, making it possible to change which of these methods is used in the implementation without breaking tests.

A new method AskStubber.StubPrompt("<prompt>") is added as test helper to supersede old Stub and StubOne methods. The new helper matches on prompt messages rather than on field names, enabling tests to be written based on what the user would see rather than coupling to implementation details.

The new stubber also allows verifying whether a Select or MultiSelect was rendered with the expected set of options. Furthermore, if a stubbed value is not present among those options, the stubber will panic instead of continuing normally.

Stubbed Selects with an int instead of a string target receiver are now transparently handled. The values for Select stubs are always strings in tests, but the stubber will write an int answer if the receiver expects one as a selected index instead of a selected string value.

Lastly, this set of changes improves test resiliency since the stubs are now matched based on prompt message (or field name for legacy stubs created with Stub) instead of sequentially, enabling the implementation to reorder the prompts without breaking existing tests.

Because the new stubbing API is no longer concerned with Survey internals, this allows us to potentially transition off of Survey in the future but keep the test stubs.

Some before vs. after:

// BEFORE
	as.StubOne(0) // template
	as.Stub([]*prompt.QuestionStub{
		{
			Name:    "Body",
			Default: true,
		},
	}) // body
	as.Stub([]*prompt.QuestionStub{
		{
			Name:  "confirmation",
			Value: 0,
		},
	}) // confirm

// AFTER
	as.StubPrompt("Choose a template").
		AssertOptions([]string{"Bug fix", "Open a blank pull request"}).
		AnswerWith("Bug fix")
	as.StubPrompt("Body").AnswerDefault()
	as.StubPrompt("What's next?").
		AssertOptions([]string{"Submit", "Continue in browser", "Add metadata", "Cancel"}).
		AnswerDefault()