This change adds a new integration which allows people to build prospective

changes via Travis CI.
The Travis CI API allows triggering a build in a way that overrides the config

from the repository's .travis.yml file. We use this to send a new

configuration which knows how to apply the patch and report the results back to

Review Board.
The configuration for the integration allows users to set the conditions

normally, with the exception that the choices for the "Repository" condition

are limited to only show GitHub repositories (since Travis CI doesn't work with

anything else). It also requires selecting which Travis endpoint to use (either

travis-ci.org for open-source projects, travis-ci.com for private projects, or

an enterprise server with a custom domain), along with providing an API token.
Currently, builds show up under the main "Branches" section of the repository

in the Travis CI user interface. Because this can pollute things (for example,

showing that the master branch is broken because a build of a review request

failed), for now I'm recommending that people create a fake review-requests

branch on their GitHub remote and then set that branch name in the integration

config. This isn't perfect, but it at least keeps review requests builds

separate. I'm starting to talk to the Travis CI folks to see if we can get some

more control through the API, perhaps even letting us list these builds in the

"Pull Requests" section instead of the "Branches" section.
The modifications made to the user-entered configuration involve changing the

script section to insert a few commands to check out the correct parent

revision and apply the patch, and modifications to the notifications section

to disable e-mail notification and set up a webhook to receive results. For

example, if the build config was set to the following:

language: python
python:
    - 2.7
env:
    - DJANGO_VERSION=1.6.11
    - DJANGO_VERSION=1.8.2
install:
    - python setup.py develop
    - pip install -r dev-requirements.txt
script:
    - python ./tests/runtests.py


Then the resulting configuration that would be sent to Travis would look

something like this:

language: python
python:
    - 2.7
env:
    global:
        - REVIEWBOARD_STATUS_UPDATE_ID=71
        - REVIEWBOARD_TRAVIS_INTEGRATION_CONFIG_ID=4
    matrix:
        - DJANGO_VERSION=1.6.11
        - DJANGO_VERSION=1.8.2
install:
    - python setup.py develop
    - pip install -r dev-requirements.txt
merge_mode: replace
notifications:
    email: false
    webhooks:
        on_start: always
        urls:
            - http://reviewboard.example.com/rbintegrations/travis-ci/webhook/
script:
    - git fetch --unshallow origin
    - git checkout 5ec2912cd1cad96a3a20ea5857e9ed2d1de0d465
    - echo <big base64 blob> | base64 --decode | patch -p1
    - python ./tests/runtests.py

Integration configuration:

Tested that only GitHub repositories showed up under the "Repository"

  condition.
Tested interaction where the server name field was hidden by default and only

  shown when the "Travis CI" field was set to "Enterprise (custom domain)".
Verified that a correct error message was shown if the API token was

  incorrect.
Verified that an incorrect configuration would show the proper errors as

  reported by the Travis CI lint API.

Usage:

Posted a variety of changes which should either fail or pass the build, and

  saw the results reported correctly.
Verified that webhook signature validation was correct, passing in regular

  use and failing if I made any changes to the payload contents.