Module Support (50%)

This adds the foundation for module support into supporting packages, but doesn't yet modify the `terraform` package to bring it into action. The reason for opening this PR early is so that we can rebase and coordinate its usage in the `f-state` branch as we redo the state which takes into account the existence of modules.

This PR, at a high level, makes the following technical changes:

  * config: supports `module` constructs
  * config: the directory that loaded a config is tracked in `config.Config.Dir`
  * config/module: A new package that is responsible for downloading, updating, and loading modules. 

This doesn't contain documentation yet because for a user nothing has visibly changed yet. Documentation will be fully covered in another PR when we complete this as part of the `f-state` branch. But in this PR, we'll mention the high level of what it looks like. 

Modules are _defined_ in no special way. They are simply directories of Terraform files. 

Modules are _used_ similar to a resource:

```
module "redis" {
    source = "github.com/hashicorp/tf-module-redis"
}
```

In addition to `source`, any parameters into Redis are present. The `source` can pull from the local filesystem, Git, Mercurial, and HTTP endpoints. HTTP must conform to a specific protocol (covered later). The source should be a fully valid URL, such as "git://github.com/foo/bar.git", but there are some shorthands available:

  * "github.com/user/repo" will become git over HTTPS.
  * "bitbucket.org/user/repo" will become git or hg over HTTPS.
  * "git@github.com:foo/bar.git" will become git over SSH.

Modules are downloaded into a local modules directory. The location of this directory is not set yet since only the API is done. 

The HTTP API is covered in `config/module/get_http.go` in the comment.