load_env damages unquoted strings

**Describe the bug**
I have a script like this:

```sh
export A=a6ed68a1cc964b430e1e40254347367f08e4eb5eeaf0852d5648022873b50c07
echo "A is $A"
./rosetta-cli --configuration-file rosetta-cli-config.json check:construction
```

And my .ros file has this in a scenario:

```
a = load_env("A");
print_message({"a": "{{a}}"});
```

The output is this from the `echo`:

```
A is a6ed68a1cc964b430e1e40254347367f08e4eb5eeaf0852d5648022873b50c07
```

and this from the `print_message`:

```
2021/12/22 11:40:18 Message: {"a": "6ed68a1cc964b430e1e40254347367f08e4eb5eeaf0852d5648022873b50c07"}
```

Notice how the `a` before the `6` is missing when accessed from within the scenario.

**To Reproduce**

1. Create an environment variable that's not JSON, i.e. where strings aren't surrounded by quotes
2. Access it from a load_env action

**Expected behavior**
Couple of weird things:

1. Something somewhere is cutting off the `a` at the beginning. My expectation is to see `{"a": "a6ed...0c07"}`
2. You need quotes around `{{a}}`, otherwise the `{"a": 6ed...0c07}` is not valid JSON. This kind of leaks the way this template stuff is done through string manipulation. Would it make sense to expect that load_env puts a value into a string and then JSON-serializes that string? Although this might break other people's use cases where they want a number or something.

**Additional context**

We use a local testnet to test our rosetta server, and each invocation of a local testnet has a unique network identifier. So we want to pass this in programmatically.