Fix issue with interpolation of strings vs charlists. Fixes #729.

[TheFirstAvenger]

This PR fixes #729. This was a fun one to track down. When we pass code into :elixir_tokenizer to identify the token locations, we first convert the string to a charlist:

credo/lib/credo/code.ex

Lines 132 to 134 in d77eab6

	source
	|> String.to_charlist()
	|> :elixir_tokenizer.tokenize(1, file: filename)

This results in column numbers consistent with the charlist indexes of the characters. For the unicode character in question (🇿🇼), it translates to two values:

iex(1)> String.to_charlist("🇿🇼")
[127487, 127484]

This means that when the :elixir_tokenizer identifies the # token in this string:

    source = ~S"""
    "🇿🇼 #{String.upcase(env)}"
    """

it identifies it at the 5th column in the output, which is correct because it is the 5th item in the charlist:

   {:bin_string, {1, 1, nil},
    [
      "🇿🇼 ",
      {{1, 5, nil}, {1, 25, nil},

The problem is that our code to split and replace that interpolation uses String.slice, which uses the String indexes, not charlist indexes, so when it grabs the 5th character, it is off by one and starts the replacement at the { instead of the #. The resulting code has an unexpected/unparsable #:

     Assertion with == failed
     code:  assert expected == InterpolationHelper.replace_interpolations(source, " ")
     left:  "\"🇿🇼                      \"\n"
     right: "\"🇿🇼 #                     \n"

The fix was simply to convert the strings to charlists and use Enum.slice instead of String.slice to replace the values, as the numbers we are working with are the charlist indexes, not the string indexes.

[rrrene]

@TheFirstAvenger Nice detective work! 👍