Pulp

jcline's done most of the work on this, but it's been transitioning on to my plate more and more. I'll be owning it entirely starting next week, so I might as well pick up the ticket now.

Updated the subject to match what I'm actually doing with this ticket. Moving the spec files into a dedicated repo per-dist is inexorable from the effort to build pulp in copr, and the effort to build in copr is stalled.

Stuff that's we can do with the new packaging scripts:
- pull down sources and build SRPMs
- tag both the source repo and spec repo with the modified sources (modified to change the version strings)
- build those SRPMs in corp or a local mock root
- being able to tag the specfile repo separately from the source repos means we finally have a way to see exactly what plugins were released for a given version of pulp in a distribution: Just look at the spec files for the tagged version.

It's subtle, but a result of this effort is that anyone with a copr can build pulp packages. Since anyone can get access to copr, this means that anyone can build pulp packages (woot).

Stuff that doesn't work:
- The packages. :( I did a test install of our copr build in fedora23, and while all the normal services (http apps, plus workers) started and appeared to log success, aiming pulp-smash at the install revealed a lot of failures. This was late in the release process for 2.10.0, so rather than dig into those failures at all, I made the decision to effectively give up and began building 2.10 using the "old" process.
- copr appears to support comps.xml, but doesn't include it when generating repodata. This isn't really a problem since we're looking to get rid of comps (#1515), and the docs for 2.10 have indeed been updated to list packages explicitly and not use package groups (at least for platform).
- on-demand repodata generation in copr doesn't work, but really should. It automatically regenerates repodata after every build successfully, but we don't want this for "stable" releases. Rather, we want to ensure all packages build successfully before regenerating repo metadata so that users get all package updates in a single atomic repo update. copr supports this, but the functionality appears to simply be broken.

I'm leaving this assigned to me, as I'll continue to tinker with this, but I'm pulling it off of this sprint. A discussion among the team leads confirms that while we do want to do this, it can (and perhaps should, in hindsight) wait for pulp 3.

The bulk of the copr work is being broken out into separate tasks. This one, as written, is probably done, since we do indeed have a packaging repo with spec files in it for pulp, its plugins, and its deps. I'd still like to clean up my devel branch related to this, which adds a lot of copr workflow bits that we'll want, so I think I'll call this done once that branch gets merged.

Apologies for not moving this to POST:
https://github.com/pulp/devel/pull/2

The devel repo isn't yet known to redmine, but the referenced PR is included on 3.0-dev in that repo:
https://github.com/pulp/devel/tree/3.0-dev

Since there's also no release structure for the devel repo, I couldn't come up with a better resolution than closing the ticket against the "master" target release.