fix os.Env precedence resolving variables in .env file

[ndeloof]

parsing dot.env file :

FOO=foo
BAR=${FOO}

and applying env var precedence rules documented here,
FOO set in os.Env should have precedence, and so value set by dotEnv file should not override AND BAR should be expanded using value from os.Env.

This rule is different from the one implemented in the original dotenv library, so the need to change the associated testcase.

closes docker/compose#10505

[glours]

LGTM

[ulyssessouza]

This PR assumes a "template" like behavior, while the previously implemented assumes a language like behavior. As there are no standards for this, I would like to take what is established in more stable software and bash behaves like the second. Ex file:

#!/usr/bin/env bash

FOO=FOO_FROM_SCRIPT
BAR=${FOO}
echo ${BAR}

When executing with:

FOO=FOO_FROM_ENV ./my-eval-test.sh

or

FOO=FOO_FROM_ENV  source ./my-eval-tst.sh

Both print FOO_FROM_SCRIPT. Which makes total sense, given that FOO was set in the line just before.
When trying to get the environment value, the default syntax should be used. Ex:

#!/usr/bin/env bash

FOO=${FOO:-FOO_FROM_SCRIPT}
BAR=${FOO}
echo ${BAR}

[ndeloof]

This PR assumes a "template" like behavior

we never pretended compose variable interpolation is anything better than templating

Both print FOO_FROM_SCRIPT. Which makes total sense

.. as a bash script, for sure, because script includes an explicit command to assign a value ad override the env var set on command line
here we are not running a script, but just declaring variables. Also, as your example demonstrates, there's no way with bash-style approach to override value, and then nested variable interpolation is at most a "don't repeat yourself" syntax candy, but doesn't offer any way to tweak the model from command line.