What problem does this feature solve?:

Anyone coming from docker should immediately recognize the -e|--env
option as apeing docker's option of the same name. Unfortunately the
circleci local execute option doesn't behave in quite the same way.
Instead of allowing you to say circleci local execute -e AWS_ACCESS_KEY_ID, for instance, it forces you to circleci local execute -e "AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}" etc.

My proposal here would be to just bring that feature from docker to
circleci. If a variable is fully specified (-e FOO=BAR) then there's
no need to read it from the environment but if it's only specified by name
(-e FOO) then circleci can just resolve it as a variable in the
environment and error if it isn't found.

This is primarily to facilitate ease of local iteration.

Provide an example:

# x.yml
version: 2.1
jobs:
  build:
    docker:
      - image: bash
    steps:
      - run: echo "$FOO"

FOO=BOO circleci local execute
FOO=BOO circleci local execute --job build
…
====>> echo "$FOO"
  #!/bin/sh -eo pipefail
echo "$FOO"

Success!
# FOO is set in the environment but is not passed to local execute in any
# way so the echo is empty.


FOO=BOO circleci local execute -c x.yml -e FOO
…
====>> echo "$FOO"
  #!/bin/sh -eo pipefail
echo "$FOO"
BOO
Success!
# FOO is specified in the environment and passed to local execute and so
# the value from the environment is used


FOO=BOO circleci local execute -c x.yml -e FOO=BAR
…
====>> echo "$FOO"
  #!/bin/sh -eo pipefail
echo "$FOO"
BAR
Success!
# FOO is fully specified so despite being set in the environment the value
# passed explicitly is used