Parsed global parameters doesn't get passed to external aliases

* When creating an alias (ie `~/.aws/cli/alias`) to an external command, the `parsed_globals` variable (ie https://github.com/aws/aws-cli/blob/develop/awscli/alias.py#L274 ) is never passed to the child-process. As a result, information is lost. Hence, the child command is actively prevented from using certain command line parameters.
* Steps to reproduce:
```console
$ aws --version
aws-cli/1.14.29 Python/2.7.14 Linux/4.13.0-25-generic botocore/1.8.33
$ mkdir -p ~/.aws/cli
$ cat > ~/.aws/cli/alias << "_EOF_"
[toplevel]
test = !echo "ENV:\n$(set | egrep -i 'foo' | sed -e 's@^@- @')\nARGS:"
_EOF_
$ aws --profile foo test subcommand --bar abc
```
* Actual output (note that all trace of the "foo" profile is lost):
```console
$ aws --profile foo test subcommand --bar abc
ENV:

ARGS: subcommand --bar abc
$ aws --debug --profile foo test subcommand --bar abc
2018-01-21 12:24:46,413 - MainThread - awscli.clidriver - DEBUG - CLI version: aws-cli/1.14.29 Python/2.7.14 Linux/4.13.0-25-generic botocore/1.8.33
2018-01-21 12:24:46,414 - MainThread - awscli.clidriver - DEBUG - Arguments entered to CLI: ['--debug', '--profile', 'foo', 'test', 'subcommand', '--bar', 'abc']
2018-01-21 12:24:46,414 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler
2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable profile from instance vars with value u'foo'.
2018-01-21 12:24:46,414 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler
2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable profile from instance vars with value u'foo'.
2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable credentials_file from defaults.
2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable config_file from defaults.
2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable profile from instance vars with value u'foo'.
2018-01-21 12:24:46,414 - MainThread - awscli.customizations.assumerole - DEBUG - ProfileNotFound caught when trying to inject assume-role cred provider cache. Not configuring JSONFileCache for assume-role.
2018-01-21 12:24:46,414 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler
2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable profile from instance vars with value u'foo'.
2018-01-21 12:24:46,414 - MainThread - awscli.alias - DEBUG - Using external alias 'test' with value: '!echo "ENV:\\n$(set | egrep -i \'foo\' | sed -e \'s@^@- @\')\\nARGS:"' to run: 'echo "ENV:\\n$(set | egrep -i \'foo\' | sed -e \'s@^@- @\')\\nARGS:" subcommand --bar abc'
ENV:

ARGS: subcommand --bar abc
```
* There are several possible solutions (mostly around https://github.com/aws/aws-cli/blob/develop/awscli/alias.py#L278-L283 ):
a. Pass a serialised, sh-escaped (which makes non-sh/bash aliases difficult to write) `parsed_globals` via a new environment variable (eg `AWS_CLI_ALIAS_PARSED_GLOBALS`) which can then be eval'ed by the child-process. This data could also be in Base64-encoded JSON (though this is now getting complicated). We could also have _multiple_ new variables (eg `AWS_CLI_PROFILE`) -- which starts to make it similar to solution 3c. Expected output then becomes:
```console
$ aws --profile foo test subcommand --bar abc
ENV:
- AWS_CLI_ALIAS_PARSED_GLOBALS='profile=foo color=auto paginate=1 command=test connect_timeout=60 sign_request=1 read_timeout=60 debug='
ARGS: subcommand --bar abc
```
b. Add it to the command-line. Unfortunately, we really need the unparsed-args. Else, we need to revert `endpoint_url` to `--endpoint-url` and I don't fancy dealing with duplicated logic. We could also modify `ExternalAliasCommand.__call__` (and `ServiceAliasCommand` etc) to transmit the unparsed args (also see: https://github.com/aws/aws-cli/blob/develop/awscli/clidriver.py#L208 ). Expected output then becomes:
```console
$ aws --profile foo test subcommand --bar abc
ENV:

ARGS: --profile foo subcommand --bar abc
```
c. For some parameters (eg `--profile`), modify the existing standardised environment variable (ie `AWS_PROFILE`) instead. However, there are no standardised variable names for most of the existing parameters. Expected output then becomes:
```console
$ aws --profile foo test subcommand --bar abc
ENV:
- AWS_PROFILE=foo
ARGS: subcommand --bar abc
```
Note that existing environment parameters exists for the following options only:
* `--profile` to `AWS_PROFILE`
* `--region` to `AWS_DEFAULT_REGION`
* `--output` to `AWS_DEFAULT_OUTPUT`
* `--ca-bundle` to `AWS_CA_BUNDLE`

And none for (if this is the desired solution, I'd also like to hear opinions on appropriate environment variable names for the following, my recommendations in brackets):
* `--color` (`AWS_COLOR`)
* `--no-paginate` (`AWS_NO_PAGINATE`)
* `--cli-connect-timeout` (`AWS_CONNECT_TIMEOUT`)
* `--no-sign-request` (`AWS_NO_SIGN_REQUEST`)
* `--no-verify-ssl` (`AWS_NO_VERIFY_SSL`)
* `--cli-read-timeout` (`AWS_READ_TIMEOUT`)
* `--debug` (`AWS_DEBUG`)
* `--endpoint-url` (`AWS_ENDPOINT_URL`)

A reason for the negatives is that by common (though not universal) Unix/Linux convention, a missing variable is treated identically to an empty string which is then interpreted as a boolean false. And given the existing default values for those variables, a `AWS_NO_` name seems more appropriate.
* As an aside, `git` solves a similar problem by selecting solution c. There are also issues which would benefit from a consistent and complete set of environment variables (eg in https://github.com/aws/aws-cli/issues/2007 the user could switch on `--debug` for all their aws-cli invocations simply by toggling `AWS_DEBUG`).
* Before I start coding up a solution, I'd like to hear from aws-cli maintainers what's likely to be merged. I want to avoid spending a lot of time coding/debugging, only for the patch to be rejected due to a difference of opinion at the very first step.