build: relax constraints of Selenium dependencies versions

[valfirst]

Change list

In a favor of flexibility the constraints of selenium dependencies versions are relaxed.

Types of changes

What types of changes are you proposing/introducing to Java client?

• No changes in production code.
• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Details

https://docs.gradle.org/current/userguide/dependency_downgrade_and_exclude.html: "conflicting strict dependencies will trigger a build failure that you have to resolve".

An attempt to use java-client:8.0.0-beta in conjunction with Selenium 4.1.0 leads to build failures, like:

   > Could not resolve org.seleniumhq.selenium:selenium-remote-driver:{strictly 4.0.0}.
     Required by:
         project :xxxxxxx > io.appium:java-client:8.0.0-beta

In a favor of flexibility the constraints of selenium dependencies versions are relaxed.

[mykola-mokhnach]

We could try that, although there were already issues about several breaking selenium API updates because of incompatible changes in their API.

Basically the question is how big is the probability that the next selenium version (minor, major or patch) is going to be incompatible to the current Appium client. And from my perspective such probability could be pretty high, since we don't only use public APIs, but rather perform many reflective calls to private/protected stuff and hack selenium lib here and there.

[mykola-mokhnach]

Maybe for now we could declare a strict version range like in https://docs.gradle.org/current/userguide/single_versions.html (Example 2):

version {
           strictly '[4, 5)'
           prefer "${seleniumVersion}"
        }

[valfirst]

@mykola-mokhnach thank you for your comments, I really appreciate them, I've updated the PR following your hints