Fix special character problem by making FindValues prefer exact matches

[v-kydela]

Fixes #4619

Description

Because the default tokenizer ignores special characters, choices that only differ in their special characters are seen as identical and our choice recognizers had no way of taking special characters into account when resolving a tie between two choices. Our choice recognition system was designed for natural language processing, but choice prompts usually allow users to click on buttons rather than typing their choices and so it makes sense to expect exact matches much of the time. This PR resolves the special character problem by checking for exact matches before any tokenization occurs.

Note that since special characters still aren't tokenized, they still aren't taken into account if an exact match isn't found. So if the choices are ":) face" and ":-( face" and the user types "I like :) face" the recognizer will still see the two choices as identical and won't be able to use the special characters to identify the correct choice. To resolve situations like that, I recommend that the developer creates their own tokenizer function as I mentioned in the issue.

Because the intent behind this fix is to accommodate the buttons created by choice prompts, I was considering a "high level" fix by putting the exact match check in ChoicePrompt instead of Find. However, I ended up going with the "low level" fix because the choice prompt code is largely duplicated in adaptive dialog choice inputs so I wanted to put this in a central place so it gets applied in all cases.

Specific Changes

• A test has been added to account for situations where multiple choices have the same word characters but different non-word characters
• Find.FindValues now checks for exact matches and bypasses the rest of its logic if an exact match is found

Testing

Included

[tomlm]

[gabog]

Approving based on @tomlm 's review