UP-4147 Add Coveralls test coverage monitoring.

Enhances the Travis-CI continuous integration build to, on each build, report to Coveralls the unit test coverage computed by Cobertura.  As tracked in JIRA at [UP-4147](https://issues.jasig.org/browse/UP-4147).  Since this happens in the `after-success` phase, failure of the Coveralls integration will not fail the Travis-CI status of the build, and only successful builds will have test coverage reporting.

uPortal currently reports test coverage in e.g. [the Maven site generated after each release](http://developer.jasig.org/projects/uportal/4.0.14/uportal-war/cobertura/index.html).  Test coverage is around 22%.

With this configuration, Coveralls will report on the test coverage and the change in test coverage in each Travis-CI-built commit and will automatically comment on pull requests as to the test coverage impact of the proposed changes.

Coveralls analytics will provide continual gentle feedback about test coverage and about the impact of specific changes and proposed pull requests in test coverage, more frequently than just on the occasion of releases with the stats buried in the resulting Maven site.  Ideally this will improve transparency about what packages and changesets are supported by how much unit testing and will "[gamify](http://en.wikipedia.org/wiki/Gamification)" the inclusion of covering unit tests in changesets by providing immediate, continuous feedback.

Examples:
* Example of [test coverage reporting](https://coveralls.io/r/apetro/uPortal) (against apetro/uPortal).
* Example of [Coveralls commenting on the test coverage impact of a pull request](https://github.com/apetro/uPortal/pull/1#issuecomment-46627642).

Known issues: 
* The configuration intended to exclude generated classes from test coverage analysis doesn't seem to work as intended, so those classes aren't being excluded ([example: `Min_.java`](https://coveralls.io/files/225158548)), and instead are dragging down the coverage stats slightly.  Annoying, but I don't think figuring that out has to block turning on this continual analysis.
[Example output](https://gist.github.com/apetro/fcfffb8c4cdab2c1061d).
How to consume: via [Coveralls visualization](https://coveralls.io/files/225159362)! :) Or via [the site Maven generates](http://developer.jasig.org/projects/uportal/4.0.14/uportal-war/cobertura/index.html).
IDE plugin and ecosystem: [yes](https://github.com/cobertura/cobertura/wiki/Projects-and-Companies-that-use-cobertura).  

Looks like [IntelliJIDE has some kind of feature for locally analyzing test coverage](http://www.jetbrains.com/idea/webhelp/viewing-code-coverage-results.html).

Note also that just because the Travis-CI continuous integration would be using cobertura and coveralls, there's no requirement that a participating developer use those tools in his or her own workflow, just as your local build process might not involve Travis-CI at all and instead use Jenkins or Bamboo or lovingly maintained `rake` scripts.

Like the Travis-CI integration itself, this is a uPortal-project-level safety net after and in addition to whatever developers do locally.