Add Puppet Forge deployment via travis-ci

This PR adds the ability to publish forge releases by updating the metadata.json file, tagging the resulting commit, and making a PR. When the PR is merged, travis-ci will publish to [ploperations/puppet](https://forge.puppetlabs.com/ploperations/puppet) on Puppet Forge.

I'm not sure whether this is how we want to do this. Here's what I like and don't like about this approach:

_Advantages_

- Very easy to cut new releases, and allows releases to follow the PR workflow
- No additional infrastructure needed because it runs through travis-ci
- We probably get a new forge release pretty soon

_Disadvantages_

- The encrypted credentials are the ploperations forge user account. Anybody with commit access could, in principle, add a shell script that would capture or display those credentials and would then have the ability to change our other modules. I'm not worried about @igalic, but it effectively significantly raises the barrier to giving other contributors commit access because it amounts to giving them publish access to all of our forge modules. Note that the credentials are *not* available during PRs, so that's not impacted.
- This is all a bit hacky:
  - We have a python script somebody else wrote that coordinates between jenkins build jobs to make sure that only one (the "leader") actually publishes and only if the others succeed. That's to work around https://github.com/travis-ci/travis-ci/issues/929. 
  - There's a shell script to do conditional checks about whether to deploy, and to manage it. I'm not sure of a better way to do that. I originally had all that logic in the .travis.yml file itself and that was even worse. I suspect this process would be pretty annoying for anybody other than me to troubleshoot.
- We lose the ability to do expected failed builds, because the python script isn't smart enough to differentiate between expected failed builds and unexpected ones, so it won't ever deploy if we have expected failed builds. This means we have to get rid of the STRICT_VARIABLES=yes check that currently fails.

I believe that this is a workable approach, but may not be worth the tradeoffs. The other option is to stand up a Jenkins (or other) CI server. Using defaults it would have many of the same problems, but we'd have more flexibility to work around them compared to using Travis.

My tentative suggestion is that we do this as an interim measure until I get around to standing up a real CI infrastructure for this project, at which point we'll run beaker tests from it and will want to switch over anyway. I'm totally open to not doing it this way; I just want to get a new release up somehow.