I _think_ `#sanitized_content` is meant to make a common Elixir pattern
safe for parsing (rather, to prevent code execution while we dependency
management is being performed). Unfortunately, there are no hints in
either Git commit history or in the pull requests that were opened
around Elixir package management.

The pattern that this is handling (at least in the fixtures in this
repo) is the case where there's a top-level file titled VERSION, which
is read in in the Mixfile's project metadata. We're handling a couple of
cases here:

```elixir
String.trim(File.read("VERSION"))  # String.trim("0.0.1")
String.trim(File.read!("VERSION")) # String.trim({:ok, "0.0.1"})
```

A lot of Elixir code relies on piping output from one function to
another, which can cause the above pattern to read as:

```elixir
"VERSION" |> File.read() |> String.trim()
"VERSION"
|> File.read()
|> String.trim()
```

We're not handling these properly, which has led to errors like:
```plaintext
(ArgumentError) cannot pipe "VERSION" into "0.0.1", can only pipe (snip)
```

This commit is meant to capture only the former pattern (nested calls),
so that we can properly handle the latter in upcoming commits.

Until this commit, we've only handled the following syntax:
```elixir
String.trim(File.read("VERSION"))
String.trim(File.read!("VERSION"))
```

However, we've encountered users using the following idioms:
```elixir
"VERSION" |> File.read() |> String.trim()
"VERSION" |> File.read!() |> String.trim()
```
and:
```elixir
"VERSION"
|> File.read()
|> String.trim()

"VERSION"
|> File.read!()
|> String.trim()
```

This commit allows us to handle the latter cases, where the pipe
operator is used.

…version-variations