Prepare new version with many fixes

[Nek-]

This PR adds:

• The fix of @bangpound for sdk
• Removes the composer.lock
• Set the environment in a better way (for at least better for Sf users)
• Improves tests
• Add support for default values for vars in getEnvVarsFromConsul method
• Throw proper exception when there is a problem with loading the configuration

But this breaks the backward compatibility by changing the signature of a constructor.

Use this fork with the following configuration in your composer.json:

{
    "require": {
        "dlapps/consul-php-envvar": "2.0.0-alpha1",
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/Nek-/consul-php-envvar"
        }
    ]
}

[bangpound]

Thanks @Nek-!

[petrepatrasc]

Hey @Nek-, thank you for the PR! Some quick remarks before we can go ahead with merging this and releasing a 2.0.0 version that contains @bangpound's changes as well.

1. Why would we not version the composer.lock file? This is a usually an anti-practice, but I'm curious as to your train of thought.
2. Why should we interact with the $_ENV object directly rather than through getenv() and putenv()?
3. Regarding defaults, I would not pass them as parameter to the getEnvVarsFromConsul() method, as this means the defaults are managed outside of the manager itself (and thus adds another thing for the consumer to fulfil). I propose that we go ahead and move this as a class dependency (or even better, create a separate class to manage the defaults and inject that as a dependency) and add a builder method for it.
4. Regarding the saveKeyValueInEnvironmentVars method that is proposed, I feel like this could be better by breaking off the HTTP functionality into two separate methods saveKeyValueInEnvironmentVars() that continues to perform as it has in the past and saveKeyValueInServerVars() that treats the $_SERVER scenario that you've described. This way we can keep the getEnvVarsFromConsul() method to make a decision based on the name of the variable, but keeps methods from doing more than one thing.

What do you think about the above? I'm happy to implement these changes quite quickly if you're also on board.

[Nek-]

The lockfile

The composer.lock is useless in the case of a library, it is ignored by composer when you install the library. Furthermore by doing this you enforce versions for your development and test environment that are not the real values of a fresh install of your library (still because composer ignores the lock file)

putenv() vs $_ENV

Here is the output of my test:

php > putenv('FOO=hello');
php > echo $_ENV['FOO'];
PHP Notice:  Undefined index: FOO in php shell code on line 1
PHP Stack trace:
PHP   1. {main}() php shell code:0

Notice: Undefined index: FOO in php shell code on line 1

Call Stack:
   51.2236     388624   1. {main}() php shell code:0

php > $_ENV['BAR'] = 'World';
php > echo getenv('BAR');
php >

Notice that Symfony team use also $_SERVER, I copied the behavior because I think it's great. I don't think filling $_SERVER is another separated task.
https://github.com/symfony/symfony/blob/9efa5551910a0389644bde012db300a82ecb75a7/src/Symfony/Component/Dotenv/Dotenv.php#L91-L93

New class dependency for default value

IMHO, overkill. But if you want to do it, I have nothing to stop you.