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.
Also, in order to reduce test time (which could cause a travis timeout) you may want to disable all test logs. The surefire plugin has a setting for the log4j location via CLI that if set to a non-existent log4j location suppresses all logs. That speeds up the test execution quite a bit. (You'd still see logs of tests fail of course)