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.
Agree this is probably unnecessarily conservative and it makes the Travis-CI build take even longer, which is unfortunate, but still puts it nowhere near the Travis-CI build duration cutoff.

I'd rather start with this excessively conservative configuration.  By cleaning first and by putting the cobertura and coveralls invocations in the `after_success` phase, they are thoroughly isolated from the existing Travis-CI build, test, and success reporting cycle.  I don't want to rush to rock the boat on something that I think is working well for uPortal.  Rather, this configuration allows trying out Coveralls without making it part of the critical path for the existing continuous integration success determination.