Allow arbitrary markdown styling for selected options in SelectionPrompt

[matthew-elgart]

This suggestion is similar to, but not the same as, #286. It's also similar in spirit to #1186 - although the implementation would probably be different, as #1186 would require changes to styles that are hardcoded as markdown directly in constants.

The need here came up while using SelectionPrompt to create a color selector as below (if there's a better way of creating a color selector, I didn't find it):

AnsiConsole.Prompt(new SelectionPrompt<ConsoleColor>()
	.AddChoices(Enum.GetValues<ConsoleColor>())
	.UseConverter(c =>
	{
		var s = ((Color)c).ToMarkup();
		return $"[{s}]{c.ToString()}[/]";
	}));

• in this setup, it's valuable to have each color option be presented in its actual color, so that the user knows exactly what color they're selecting - hence the markup
• therefore, the default behavior of coloring the current selection blue wasn't what I was looking for
• similarly, .HighlightStyle() couldn't help me here, because it uses a single style for the selected option, whereas I want the color to vary for each option (e.g. I want the option for Red to always be colored red, and so on - I don't want it to be colored gray when selected)
• of note: when I have the options formatted with markdown as above, non-selected options are colored the way I want. It's only the highlighted option that ignores the markdown.

The rub seems to be these lines, which remove the markdown from the selected option so that HighlightStyle can be applied. What I'm looking for is a way to (sometimes) keep the markdown formatting.

Interestingly, HighlightStyle already supports a null value. It's not used; if it's null when creating a prompt we just use the Blue styling. Therefore the proposal would be:

• update the HighlightStyle property to initialize to new Style(foreground: Color.Blue) so that default behavior remains the same
• update the HighlightStyle() method to accept a Style? rather than a Style
• update the lines above where markdown is removed to check for current && style != null

I actually tried the proposed fix out and created a local package to use for my own project, so I believe that this would work. I don't think it causes any source/binary incompatibilities - but it would change the behavior if any users were explicitly setting the HighlightStyle property to null for some reason (prior to the change that would result in blue styling; after the change it would result in either default or markdown'd styling).

I don't think anyone would actually be doing that, though. I think the bigger question is whether this API is actually something the user would expect. It's possibly not intuitive that the default HighlightStyle would be something other than null, or that explicitly setting the property to null would have the effect of allowing markdown styling for the highlighted option (counterpoint: arguably having the default styling be arbitrarily blue isn't very intuitive either).

In any case, since I've already made this change locally, if it's something that would be valuable, I'd be happy to make this change!