Switch to Travis for CI and production deployment

 - Add .travis.yml configuration

 - Update Gradle `deploy` task with awareness about Travis CI build
   environment. Only go through with production deployments if on master
   and Travis's "secure environment variables" are present (they are not
   in the case of pull requests from forks). See
   http://docs.travis-ci.com/user/encryption-keys
   http://docs.travis-ci.com/user/build-configuration/#Secure-environment-variables
   http://www.gradle.org/docs/current/userguide/userguide_single.html#sec:gradle_properties_and_system_properties

 - Eliminate `ci-deploy.sh` entirely in favor of the above

 - Send HipChat notifications to the Sagan room

 - Set TERM=dumb in order to produce clean Gradle console output in the
   Travis web UI. See
   http://stackoverflow.com/questions/17942819/how-can-i-get-clean-gradle-output-on-travis-ci

 - Disable git submodule processing by Travis build, as it was causing
   problems. It's unnecessary in any case, as it's just the wiki. See
   http://docs.travis-ci.com/user/build-configuration/#Git-Submodules

 - Update README build status badge to reflect Travis CI vs. Bamboo

 See https://travis-ci.org/spring-io/sagan
Merge pull request #331 from spring-io/travis
Temporarily ignore BasicAcceptanceTests
Update license, notice and readme files

 - Fix typo: GPLv3 now reads BSD-3 in README
 - Separate LICENSE from NOTICE files for clarity and readability
Merge pull request #335 from spring-io/fix-license
Add Disqus comments to blog posts

Per instructions at
http://spring-io.disqus.com/admin/settings/universalcode
Sync wiki submodule
Add comment re: NEW_RELIC_APP_NAME assignment bug

See #262
Reduce the number of indexer instances from 4 to 1

There is no need to run 4 indexer instances; indeed, doing so is
undesirable when considering that any number greater than 1 instance
results in competetion without coordination, meaning the same content
gets indexed and re-indexed for no reason and with no benefit.
Revert "Add Disqus comments to blog posts"

This reverts commit 38565e10abb403c9371318b626d05738b08f2f24.
(Unintentionally committed)
Support -Pspace=<...> vs. -Pproduction / -Pstaging

Prior to this commit, deployment required specifying

    ./gradlew deploy -Pproduction # OR
    ./gradlew deploy -Pstaging

This worked fine, but required unnecessarily complex conditional logic
in deploy.gradle. This change refactors this logic such that -Pspace is
required and the value is treated as the target space. 'production' is
treated as a reserved value and gets special treatment, e.g.:

 - 'panda' database instead of default 'hippo'
 - 'spring.io' and 'www.spring.io' URIs are mapped, instead of the
   default '${space}.spring.io'

If the value of the space property is anything other than 'production',
then the defaults mentioned above apply instead.

If the space property is not present and the build is running on Travis
CI, the implementation now looks to the name of the current git branch
to determine the target space. This allows us to push changes to master
in order to deploy to production, and to push branches named stage-foo,
stage-bar, etc to deploy to staging.

See also #331
Merge pull request #337 from spring-io/space

Support -Pspace=<...> vs. -Pproduction / -Pstaging
Add Disqus comments to blog posts

Per instructions at
http://spring-io.disqus.com/admin/settings/universalcode, three 'sites'
have been set up at Disqus under the 'saganops' account:

 - spring-io (production)
 - spring-io-staging
 - spring-io-localhost

Depending on the active Spring profile (see changes to application.yml),
one of these names will be exposed to the frontend via BlogController as
'disqusShortname'. See changes to _full_post.html to see where this is
assigned to disqus_shortname.

Comment threads are correlated with individual posts using
disqus_identifier, which is assigned the (unchanging) database id of the
post being rendered.
Make fields private where possible
Merge pull request #334 from spring-io/disqus

Add Disqus comments to blog posts
Upgrade to Spring Boot 1.0.0 GA

Implicitly upgrades to Spring Framework 4.0.3 in as well
Remove @EnableTransactionManagement

Now implicitly enabled in Spring Boot 1.0.0 GA. See
spring-projects/spring-boot#576
Switch from libs-milestone to libs-release

And remove libs-staging-local, now that Spring Boot 1.0.0 GA is
released.

Results in the following:

    FAILURE: Build failed with an exception.

    * What went wrong:
    Could not resolve all dependencies for configuration ':sagan-common:compile'.
    > Could not find org.cloudfoundry:cloudfoundry-runtime:0.8.4.
      Required by:
            sagan:sagan-common:unspecified

It appears that this artifact only exists in libs-milestone-s3-cache.
See http://imgur.com/PlFpD9s. Why is this? Shouldn't it get cached when
it is requested it via libs-release?