Add build class, rework data model, add PL jenkins builds

This PR reworks the packaging repo fairly significantly. This PR adds a BuildInstance class to packaging, whose purpose it is to store, display, write and ingest data about build parameters. When a build task is invoked, a BuildInstance object is created and populated with data from the build_defaults and project_data yaml files, and if appropriate, also from the extras build_data. The build object includes behavior for writing all build parameters to a yaml file, printing to string, and reading them in from yaml files. A new environment variable, PARAMS_FILE, can be passed as the path to a complete params file, and the build object will solely use this for data instead of build_defaults and project_data. The implications are felt with remote tasks. This PR modifies the remote task system to write a params file locally with all known build parameters, ship it to the remote builder with the package, and use it to populate build parameters instead of the current terribly confusing mix of local and remote environment variables and yaml files. This PR also paves the way for a queuing system, because the params files contain basically everything needed for a build.

The second major revolution this PR introduces is the ability to build jobs remotely via release-jenkins, instead of via ssh into builds. This is accomplished in tandem with the jenkins job here: http://jenkins-release.delivery.puppetlabs.net/job/puppetlabs-packaging/. The workflow allows jenkins to handle parallelizing our builds instead of us doing it, and allows us to walk away and check back in later. Signing is accomplished by retrieving the packages, sending them out to a host with appropriate signing ability, and retrieving all signed artifacts. Builds are stored by jenkins on the distribution server under /opt/jenkins-builds/$project/$sha, where $sha is the sha of the commit that was packaged. Original built artifacts are under /artifacts. When shipping signed artifacts, to production, the final artifacts are stored under /shipped. This PR also introduces automatic repository creation for debs and rpms under /repos with the packages that have been built.  Once repos are built, yum and apt configurations for every repo are automatically generated, and can be used on acceptance hosts for installing the packages. The jenkins workflow also allows for triggering a downstream job, by passing DOWNSTREAM_JOB= to the pl:jenkins:* job.  Very importantly, this is essentially a drop-in replacement for the existing release workflow, but maintains complete backwards-compatibility with the old one. The old one still works, but jenkins can do it to. Whereas before, pl:uber_release was all we needed to ship, with the jenkins workflow it is pl:jenkins:uber_build followed by pl:jenkins:uber_ship for retrieval, signing, and shipping.