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.
I would suggest for this line to happen as part of the default script, rather than after success. The default script should be `mvn package` which would run tests for you, and if there are any failures there, you wont get a success. Besides, you'd effectively be running the build twice which not only takes quite a bit of additional time, but also could cause weirdness on the travis side. (Seems like every maven command is isolated and clones a new m2 directory)