EPP fails if token value begins with YAML-like structure

Updating the IS and title to be more exact. This is an issue when the replaced token value begins with YAML-like syntax.

Also just want to note that other YAML-like structures in replaced values will also parse to undesired results in $value. For example, a token value of [ foo, bar, baz ] results in a $value of:

[
  0: "foo",
  1: "bar",
  2: "baz",
]

A bit of a contrived value for sure, but rules out the "replace colon space with colon  " kludge.

Regarding rawurlencode/rawurldecode-ing token values:

Using rawurlencode() on replaced token values has potential, as it maps pretty nicely to YAML's special/reserved characters. But, especially where formatted text (html) is involved, it's very likely to produce values that will throw exceptions when sent to the YAML parser (e.g. strings that start with "%"), so the entire values also need to wrapped in quotes.

Once parsed, replaced values would then need to be un-quoted and passed through rawurldecode(). Depending on what was actually in the EPP value field, that can get tricky. Was there YAML? We need to recurse through any resulting array. What if there was other text in the field? [Scratches head].

Here's a patch that does a bit of "custom encoding/decoding" to prevent replaced token content from being parsed as YAML key/value pairs. This doesn't address the "other YAML-like structures" I mentioned in #2.

I didn't start a branch or open an MR, as I feel like this is only a temporary/partial fix, but might be the basis for more robust solution.