Create variants for Java and CDT

[ThyMYthOS]

Not sure if we can have several variants in the same git repo.

[lucyllewy]

Can you verify that these changes are still needed and re-roll if necessary? at the least it seems your branch needs to be synchronised before it can be merged. Sorry this PR was abandoned so long... It's fine to close the PR if it isn't still needed

[ThyMYthOS]

It seems that tracks are now the right way to publish different Eclipse flavors. (https://snapcraft.io/docs/channels)
Those should be requested on #store-requests, but it's not clear how to automatically build for the different tracks.

Maybe it's even better to publish separate snaps in order to allow parallel installation of different flavors.

[merlijn-sebrechts]

I agree that publishing separate snaps is better.

The easiest way to set this up is to create a separate repository for each snap. However, that will make maintaining the snaps a bit harder.

It might be better to have multiple versions of the snap in a single repository, so we can update them all in a single PR. However, then we will have to switch from using the snap store build service to GitHub actions, like I'm doing with signal-desktop right now: snapcrafters/signal-desktop#81

If you're interested, I can help you out to set up the GitHub actions once I'm done with signal-desktop. In that case, you would need to update this PR to resolve the conflicts. Two notes:

• You can remove the travis stuff since we switched from travis to github actions
• eclipse-java should keep the snap name eclipse, since we can't change the name of a snap and it's already published in the store.

[jnsgruk]

@ThyMYthOS this PR is a little stale, but there might be an alternative route now.

Our CI now supports publishing to multiple tracks where each track is represented by a different branch in the repo.

We could theoretically have 1 eclipse snap, with a latest track, cdt track and java track.

@merlijn-sebrechts wdyt?