Fix inconsistency with .env loaders out of the box

[ostrolucky]

Description of changes:

PHP .env loaders such as symfony/dotenv or vlucas/phpdotenv populate $_SERVER out of the box, but don't call putenv() in order to preserve thread safeness. This means .env is loaded by them, but AWS SDK does not read it, creating inconsistent experience when handling real env variables and env variables loaded by these loaders.

With this change, we are still reading via getenv() by default, but fallback to $_SERVER in case getenv() doesn't give back anything. Can be easily extended later to other global variable holders like $_ENV

[GrahamCampbell]

As the maintainer of phpdotenv, $_SERVER is the best place to look at for env variables. PHP's naming of things is kinda confusing.

[ostrolucky]

I decided to stick to $_ENV, because in this case variable is used only as fallback in cases where getenv() does not work. getenv() should work in all the cases, except the cases with .env loaders. Loaders do populate $_ENV in those cases though. Using $_ENV here is more semantically correct and we don't risk exposing something else as $_SERVER contains other garbage too, outside of env vars.

[GrahamCampbell]

$_ENV here is more semantically correct

Not really. PHP's naming is confusing like I said. $_SERVER is the closest thing to getenv. It does contain other stuff, but $_ENV is also missing stuff!

[ostrolucky]

Again, $_ENV is not missing stuff in combination with getenv(). getenv() ?: $_ENV is more semantically correct in this case than getenv() ?: $_SERVER. Your proposal would make sense only if there was no getenv() call.

[ostrolucky]

Just to clarify why I don't just replace getenv() calls with $_SERVER:

1. Even though unlikely, $_SERVER can be disabled through variables_order directive. getenv() cannot
2. $_SERVER is not populated under PHP's built-in web server (and possibly other SAPIs)
3. It would require changing lot of lines of code compared to just importing this function