[WIP] escript-related mix tasks

This PR implements a few additional escript-related mix tasks, outlined in [this proposal](https://groups.google.com/d/msg/elixir-lang-core/LEr5Vjd1gys/A8WTbC1vmhwJ).

## Technical details

  * `mix escript.install` has been added that works similarly to `mix archive.install`: it takes a path or a URL to an arbitrary file and puts it under `~/.mix/escripts`.

  * `mix escript` lists all executable files under `~/.mix/escripts`.

  * `mix escript.uninstall` removes the file with the given name from `~/.mix/escripts`.

## Additional concerns

  * the ability to escript.install a prebuilt escript has been added because archive.install could already do that for .ez files, and it makes even more sense to have this work with escripts as they are not dependent on the installed Elixir version.

  * there is no environment variable MIX_ESCRIPTS because, as I mentioned, escript are generally independent of the installed Elixir version.

## TODO

  * [ ] tests

  * [ ] to keep `archive.install` and `escript.install` symmetric, both should be able to fetch repositories and hex packages. The package will be fetched into a temporary directory, in the case of an escript it will also fetch dependencies. Then everything is compiled and subsequently `archive.install` or `escript.install` is called with the resulting archive or escript file. This makes it possible to host mix tasks on hex.pm too.

  * [ ] the command-line invocation syntax is just an idea. I have considered lots of alternatives, but would like to hear what the team thinks about it first. We can't really say that it is similar to the dep syntax in mix.exs because that would mean having something like this:

        mix escript.install phoenix
        mix escript.install phoenix 1.0.2
        mix escript.install phoenix github phoenixframework/phoenix

  I would much rather have the Mix task infer the source type from the URL given to it. The biggest problem is then to distinguish a local path from the package name.

  * if we allow both archives and escripts to be fetched from hex.pm, it may be confusing in which way a given package is supposed to be used: as a dependency, as an archive, or as an escript. Perhaps, hex.pm could indicate that visually in some way, or via the project's name.
In the case of `https://example.com/foo.git` above, Git would be inferred from the trailing `.git` part.

After some consideration I see the appeal of sticking with your proposal because of its similarity with dep syntax. It doesn't define a few things though. What is your take on these cases?

```
escript.install ./local_file        # ./ is used to distinguish from a hex package
escript.install path/to/local_file  # cannot be a hex package, so it can imply a local path
escript.install path path/to/local_repo  # ugly

# What about this? Should we forbid fetching remote scripts?
escript.install ??? https://example.com/escript_file
```

I realize that in the common case hex packages should be preferred, but we still have to define what happens with the other cases.

The ambiguity of supporting a prebuilt escript could be solved with a dedicated task:

```
escript.install-file local_file
escript.install-file path/to/local_file
escript.install-file http://example.com/escript

# or a flag

escript.install --file local_file
# etc...
```

It may not be all too important to be able to install prebuilt escripts, but leaving it out makes it feel incomplete.

What do you think, @josevalim, @ericmj ?