Create Mason API & Server

It would be interesting we were able to create a lightweight client such as has been proposed in #187, but the information on how and where builds are completely seperate from the client.

The Mason server would live on an address such as https://mason.mapbox.com/. Several simple endpoints would exist for this server such as:

https://mason.mapbox.com/download which would be a request to download a specific package, you would provide a simple JSON object that you would POST to this endpoint.

{
    "package": "geometry",
    "version": "v0.9.0",
    "arch": "osx",
    "type": "debug",
     // Other options here
}

The server would then respond either with a path to download or would simply provide a 307 HTTP code redirect to the s3 location for the proper file to be downloaded or some other structure. We could also provide back an expect hash for the file if we wanted to simply return a path and hash as a JSON response

{
     "package": "geometry",
     "build": 4313,
     "path": "https://mason.mapbox.com/geometry/4313/build.tar.gz",
     "hash": "12345123412341234g34123",
}

This would be nice because we could then use a database to manager the list of packages and provide a friendly user interface perhaps for managing of these packages. Additionally we could have rebuilds a single version of a package and point to the "correct" one for each version so we are never accidentally blasting over a build.

Additionally it would be easy to provide back a list of all the packages for a specific version:

https://mason.mapbox.com/list

{
    "package": "geometry",
    "arch": "osx",
    "type": "release",
    // other options
}

the server then could respond back with JSON with something such as:

{
     "package": "geometry",
     "versions": [ "0.4.0", "0.5.0", "0.9.0" ]
}

Start by reviewing the existing Mason client and build handling, along with the client proposal in issue #187; this issue names no implementation files or tests. The work would need a decided API design for the /download and /list endpoints, package and build metadata, and storage or redirect behavior before implementation can be considered done.