Using case insensitive storage type names

### Describe the bug

As developer configuring the storageTypeInfo of a Catalog, I see the storageType attribute is expected to be case sensitive e.g. `s3` and `S3` are treated differently. As a result my API call fails with message saying unsupported storage type.

### To Reproduce

1. Assuming you got Polaris server running
2. Create a Catalog with
```json
{
"catalog": {
"name": "my_catalog",
"type": "INTERNAL",
"readOnly": false,
"properties": {
"default-base-location": "s3://mycatalogs"
},
"storageConfigInfo": {
"storageType": "s3",
"allowedLocations": ["s3://mycatalogs"]
}
}
}
```
4. The call will fail and checking logs you will find info saying `s3` storage type is not support and supported types are ...
5. Now update the JSON to be
```json
{
"catalog": {
"name": "my_catalog",
"type": "INTERNAL",
"readOnly": false,
"properties": {
"default-base-location": "s3://mycatalogs"
},
"storageConfigInfo": {
"storageType": "S3",
"allowedLocations": ["s3://mycatalogs"]
}
}
}
```
6. The API call will succeed.

### Actual Behavior

Currently the API call succeeds only with `S3` as storageType

### Expected Behavior

It will be great if the system can handle the right case insensitive storage type names.

### Additional context

_No response_

### System information

OS: Linux Container
Object Storage: S3

Start at the Catalog storageConfigInfo handling and the validation that reports supported storage types. Reproduce catalog creation with both lowercase and uppercase storageType values, then verify that valid case variants are accepted while unsupported types remain rejected.

Written by the indexing model from the issue text.