Previously, to fetch data out of the `*config.Configuration` type, a reference
to a `Fetcher` was used, a-la:
```
cfg.Env.Get(...)
```
This is quite convenient, however, it forces the LFS client to implement
several methods more than once. Consider the interface:
```
type Fetcher interface {
Get(key string) (val string)
Bool(key string, def bool) (val bool)
// et. al.
}
```
In order to return typed information from a configuration instance, _each_
`Fetcher` must implement its own `N` methods for `Int`, `Bool`, etc.
To remedy this, the `Environment` type was introduced. It instead _has_ a
`Fetcher`, and defines its own type conversions, like so:
```
type Environment struct {
f Fetcher
}
func (e *Environment) Bool(key string, def bool) (val bool) { }
func (e *Environment) Int(key string, def int) (val int) { }
// et. al.
```
Now, the `config.Configuration` type holds a reference to an `Environment`, and
all type conversion methods are defined only once, saving time, and enforcing
consistency across multiple sources.
The `SetAllEnv` function is one of two functions that allow for mutable
behavior within the `*config.Configuration` type. It is desirable for us to
remove that function, and all of its uses throughout the LFS codebase.
Unfortunately, a lot of `SetAllEnv` uses are coupled to initializing the
`config.Configuration` instance with custom `.gitconfig` data, a-la
`NewFromValues`. This coupling makes it difficult to write an atomic commit
that *only* removes the usage of `SetAllEnv`.
As a compromise, the signature of `NewFromValues` changed from:
```
func NewFromValues(gitconfig map[string]strimg) *Configuration
```
to...
```
type Values struct {
Git, Env map[string]string
}
func NewFrom(v Values) *Configuration
```
To support reading fixed data as a part of the `Env` fetcher, a new Fetcher
type was introduced:
```
type mapFetcher map[string]string
func (m mapFetcher) Get(key string) (val string) { ... }
```
and is used in place of the old `*EnvFetcher` to retrieve data from the
"environment".
