exansion of ENV variables in configuration options leads to memory leaks

Nobody has claimed this yet.

The code to expand environment variables in configurations values makes a copy of the env variable value using `strdup()` but is the only case where `scr_param_get()` returns a copy so that users cannot call `free()` on its return value. The relevant code snipped looks like this:
```C
value = kvtree_elem_get_first_val(scr_system_hash, name);
if (value != NULL) {
/* evaluate environment variables */
if(*value == '$'){
// RH: this case returns a copy while all others do not
value = strdup(getenv(value+1));
}
return value;
}
```
and appears a couple of times in `scr_param.c`.

A related issue is the code in `param_get_hash()` around

https://github.com/LLNL/scr/blob/82a3c43d8243c61fac331b64539535f6cdfa3961/src/scr_param.c#L152

namely

```C
for (elem = kvtree_elem_first(value_hash);
elem != NULL;
elem = kvtree_elem_next(elem)){
char* value = kvtree_elem_key(elem);
if(*value == '$'){
value = strdup(getenv(value+1));
elem->key = value;
}
```
which overwrites the `elem->key` of the found value hash with the expanded value of the env variable.

This:

1. leaks the memory that `elem->key` pointed to before
1. modifies `value_hash` which is a reference to the existing hash that was found (and at least in my opinion should be modified by a "get" function)

Read src/scr_param.c at scr_param_get() and param_get_hash(), then trace their callers to establish the intended ownership of returned values and hash keys. Done means environment-variable expansion no longer leaks the original key or returned copy, and a get operation does not mutate the existing value hash; validate this with the relevant configuration paths and memory checks.

Written by the indexing model from the issue text.