Introduce new travis beta-feature of Build Stages

[TheSnoozer]

Build Stages allow to group the build into different categories (similar to a pipeline).
I think this a feature we can make a use of since we kinda have two sets of tests. The first set of tests is the normal integration test and the second set is the matrix build that is currently performing a full integration test with various maven versions. Travis new feature of build stages pretty much helps us to group those into different categories. By default all the normal tests (mvn clean package) are executed in parallel. However if those tests fail it would be a waste of resources to also run the full integration tests (mvn clean install && mvn clean initialize -Pdemo) since we already know something is broken. The build pretty much only advances to the next build stage if the current build stage has been passed and executes all tests inside the stage in parallel.
Only downside is that the entire build may take a bit longer (nothing dramatic for this plugin) since the second stage is not being touched before the first one fully finished (longest job in first stage runs 1min 20s).
In general I think this should still be introduced for the fact that we use travis for free and if the build fails early during integration tests there is no reason to create another 10 jobs

Official Documentation (https://docs.travis-ci.com/user/build-stages/)

Build stages is a way to group jobs, and run jobs in each stage in parallel, but run one stage after another sequentially.

In the simplest and most common use case, you can now make one job run only if several other, parallel jobs have completed successfully.

Let’s say you want to test a library like a Ruby gem or an npm package against various runtime (Ruby or Node.js) versions in parallel. And you want to release your gem or package only if all tests have passed and completed successfully. Build stages make this possible.

Of course, there are a lot more, and a lot more complicated use cases than this one. You can, for example, also use build stages to warm up dependency caches in a single job on a first stage, then use the cache on several jobs on a second stage. Or, you could generate a Docker image and push it first, then test it on several jobs in parallel. Or, you could run unit tests, deploy to staging, run smoke tests and only then deploy to production.

[ktoso]

Interesting feature, will want to read up more about it :)
Sounds good