Upgrade Neo4j server and driver dependencies.

[meistermeier]

This PR upgrades

• Neo4j server from for testing and as the (deprecated) default to 4.4.1.
• The Neo4j Java driver for testing to the most current 4.4.2.

Two things that I would like to improve but do not know how to solve them:

1. Having to explicitly say that the database from the test-resources needs to get upgraded every time. @michael-simons https://github.com/testcontainers/testcontainers-java/compare/master...meistermeier:upgrade-neo4j?expand=1#diff-7f1bb307bc0ede77f2ef4beb5966f2187e591768eabeb9733b4796df6a689137R50
2. For testing purposes we have to build a minimal plugin against the Neo4j 3.5 API and cannot use the better fitting 4.4.x library because Neo4j 4.x has a JDK 11 baseline and as a consequence I cannot compile a 4.x plugin with the current build pipeline (JDK 8). @kiview I heard you know somebody who knows how to use Gradle's toolchains ;)

[kiview]

LGTM, WDYT about removing Neo4jTestImages?

[rnorth]

We're a bit cautious that simply looking at the start of the version/tag could be a bit fragile in the case of custom images that people may be using, or simply surprising version numbers from any source.

Please could you have a look at how a similar problem is handled in LocalStackContainer?
https://github.com/testcontainers/testcontainers-java/blob/master/modules/localstack/src/main/java/org/testcontainers/containers/localstack/LocalStackContainer.java#L100

There are three main facets which (I hope!) add up to a safer implementation:

1. use our ComparableVersion utility class to do a semver comparison, not startsWith
2. gracefully fall back if a custom or non-parsable version is found - clearly logging what’s happened and how to change it
3. provide a constructor to allow the automatic version detection to be overridden, if a custom version string is being used that clashes with the original

It's not perfect - edge cases can still exist - but this seems to be working well for users.

[meistermeier]

Thanks for your feedback. I changed the code to use ComparableVersion (hopefully right).
I refrained from the additional constructor because the feature can only used with older versions of Neo4j already today.
I do not want to have
a) an additional constructor added to the mix of the already available ones. This could confuse the users.
b) encourage users to use an older version for convenience
Both might even result in users trying to somehow hack their way around the restriction and end up with a broken database inside the container.

[rnorth]

@meistermeier thanks for switching to using ComparableVersion and for explaining your intentions around the constructors. I think this is fine, on balance, and am happy to approve.