Feature request: Add the `like()` function for string pattern matching

[johnlokerse]

Is your feature request related to a problem? Please describe.
No. It benefits the authoring experience.

Describe the solution you'd like
Add a new function called like() to the list of string functions. Like must support two parameters, one for input and one for the matching value. Matching is done with wildcards (*).

This function benefits the user in flexibility for matching strings and it can simplify if/else statements. Additionally, it would benefit readability, maintainability, and it would be a great addition to the existing string functions such as contains, startsWith and endsWith.

like

like(stringToMatch, matchValue)

Parameters

Parameter	Required	Type	Description
stringToMatch	Yes	string	The string that needs to be matched
matchValue	Yes	string	The value to match

Return value

True if the item is matched; otherwise, False.

Examples

param someString string = 'OneTwoThree'
param someArray string[] = [
	'One'
	'OneTwo'
	'OneTwoThree'
]

output matchTrue bool = like(someString, '*Two*')
output matchFalse bool = !like(someString, '*Two*') 
output matchArrayTwo array = filter(someArray, value => like(value, '*Two*'))
output matchArrayThree array = filter(someArray, value => like(value, '*Three'))

The output from the preceding example with the default values is:

Name	Type	Value
matchTrue	bool	true
matchFalse	bool	false
matchArrayTwo	array	[ 'OneTwo', 'OneTwoThree' ]
matchArrayThree	array	[ 'OneTwoThree]

[anthony-c-martin]

In the long run, we have plans to introduce regular expression matching support for Bicep, but there are some downsides:

• Pessimistically we're probably talking about this being ~2 years off - it's dependent on a complex service migration, and an experimental NuGet library.
• Regular expressions are very powerful, but perhaps overkill for some simple use-cases like the ones described above.

Normally we try to avoid introducing features that are duplicative, but given the above, I'm inclined to say we should do both - would like some input from others:

• As long as the feature-set is extremely limited, and we are happy keeping it this way (basically just supporting *), this should be really cheap and quick to implement.