Type flags are lost when value is transformed via runtime function

**Bicep version**
Bicep CLI version 0.14.6 (f1dae160cd)

**Describe the bug**
Since the latest release (v0.14.6) of the Bicep CLI, type narrowing is being applied when using the `@allowed` decorator on parameters. According to [the official docs](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/parameters#allowed-values), these constraints should be applied when an argument is passed into the param.

With the recent change (in v0.14.6), the type for the parameter now becomes the union of the literals supplied in the `@allowed` decorator, which makes compilation fail when trying to supply any value that is not one of the exact types present in the union type, even when the value of the argument is actually the correct value.

AFAIK there are no ways to cast variables to a specific type (so that we can provide the value as an argument to the parameter with the correct type) which breaks the possibility of using any functions for string manipulation, because the returned type is always `string`, and can thus not be given as an argument to the param.

I believe this is an (unintended?) bug, and should be reverted to the previous behaviour of not changing the actual type of the parameter, and instead just apply the constraints during validation of the template.

**To Reproduce**
Steps to reproduce the behavior:
```bicep
// module1.bicep
@allowed([ 'dev', 'prod' ])
param env string
```

```bicep
// main.bicep
param inputWithEnvSuffix string // e.g. 'something-dev'
var environment = split(inputWithEnvSuffix, '-')[1]

module mod './module1.bicep' {
name: 'some name'
params: {
env: environment
}
}
```
yields the following error in `main.bicep`:
`The property "env" expected a value of type "'dev' | 'prod'" but the provided value is of type "string".bicep(BCP036)`

**Additional context**
This worked fine in Bicep CLI version 0.12.1 (e43d137c2d)

Start by compiling the two-file reproduction in module1.bicep and main.bicep with the Bicep CLI versions mentioned, and compare the reported type error. Trace how @allowed values affect the module parameter type and how the transformed string is checked. Done means runtime string transformations can supply valid allowed values while the constraints still validate the argument.

Written by the indexing model from the issue text.