Use case description

Support .env files for environment variables resolution (as resolved via dotenv package).

Proposed solution

To not collide with serverless-dotenv-plugin in initial implementatin this functionality should be hidden behind an option (I propose top level: useDotenv, which should default to false).

That means any variables saturation is possible only after first service config read at

Therefore at this point:

if useDotenv was set to true

1. Populate process.env with any variables in eventual .env file
2. Populate process.env with any variables in eventual .env.${stage} we can resolve stage via:

this.processedInput.options || _.get(this.pluginManager.serverlessConfigFile, 'provider', 'stage') || 'dev'

if useDotenv was not set

If we detect the .env or .env.${stage} file in service folder, we should communicate via deprecation message that native support for dotenv was baked in, and with v2, environment variables from those files will be loaded by default. and that to hide this message user should either set useDotenv to true (to load vars), or remove .env` vars