eclipse-base and eclipse-wtp refactoring

[fvgh]

This PR provides a refactoring of eclipse-base configuration aiming to make the configuration more readable and thread save.
Further more the configuration provides support for Eclipse bundles without activator, as for example required by org.eclipse.core.filesystem 1.7.600.

The eclipse-base changes are applied on WTP. Furthermore WTP has been refactored to disallow multiple instantiations with different configurations. The previous approach was not thread save as reported in #492

For demonstration purpose, the new eclipse-base configuration has been applied on all other eclipse formatters as well.

Note that for building eclipse-base sub-project has to be published first.
As result of this PR the new versions of eclipse-base and eclipse-wtp shall be published on maven central.

[nedtwigg]

This LGTM. Ready for me to publish? Also, are you okay if I adopt spotless-changelog in these _ext projects? The main change would be:

• instead of ### Version x.x.x - TBD it would be ## Unreleased
• when we publish to maven central, the tooling will automatically replace with ## [3.2.2] - 2020-03-02

Relatively small change, but takes one little bit of administrivia out of the equation.

[fvgh]

@nedtwigg
I applied spotless-changelog, please have a last look at 8e2c7c7.
Not sure when you update the log (on branch or master).
Feel free to merge and publish (eclipse-base and eclipse-wtp) in which order (publish/merge) you prefer.
As soon as the new versions are available, I'll provide an update for lib-extra, fixing #492.

[nedtwigg]

Sorry it took me so long, and sorry I broke the build for a bit in the middle. Publishing logic is always a little tricky to test :)

[nedtwigg]

Just FYI, I merged this history into master, so that the published tags are ancestors of master.

[fvgh]

@nedtwigg I see the point. But in this case it would be better next time to merge accepted changes first and than do the publishing, wouldn't it?

[nedtwigg]

I think you are correct, and I will do it that way from now on.

Now that we have adopted spotless-changelog, it will be possible for us to cut a release using CircleCI triggers. I haven't used it before, but I think there would be a committer-only dashboard, and you could push the "release eclipse-base" button, and it would calculate the version, publish to mavenCentral, bump the changelog, tag, and push. It's a nice blend between automatic and manual.

Not sure when I'll have a chance to work on the CircleCI thing, but that is the motivation behind the churn I introduced with spotless-changelog.

[fvgh]

Interesting. Like to see it running.

[nedtwigg]

Released in x.28.0