Simplify custom tests

[uuf6429]

The base TestCase from driver-testsuite has some disadvantages:

• it tends to require some additional boilerplate for most driver-specific tests
• it's a bit unclear/convoluted for simple test scenarios
• in principle, tests requiring mink/getSession() are probably misplaced and should exist in the driver testsuite when you think about it

With that in mind, I came up with a simple base TestCase class that copies some of the functionality of the original one.
In my opinion, we should make helper traits out of the original one, which driver authors could use - but that's a bit off topic.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.61%. Comparing base (9afb55f) to head (4e6615f).

Additional details and impacted files

@@             Coverage Diff              @@
##               main      #43      +/-   ##
============================================
+ Coverage     84.21%   84.61%   +0.40%     
  Complexity      194      194              
============================================
  Files             1        1              
  Lines           494      494              
============================================
+ Hits            416      418       +2     
+ Misses           78       76       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aik099]

Now I've got the core idea behind this PR: if we want to test the driver, then we need to instantiate driver class and only call it.

Currently, in the driver test suite, we use NodeElement and Session to manipulate the driver, but that only slows things down and makes it harder to understand what driver calls are actually made. We're basically testing the Mink Driver using the Mink itself, which is a bad practice.

You can suggest a driver test suite rewrite idea at https://github.com/minkphp/driver-testsuite , but I'm not sure who will volunteer to rewrite a test suite, that already works.

[stof]

For custom tests covering driver-specific configuration settings, using the driver directly makes sense (and is what we already do in a bunch of tests of other drivers).
However, for the shared tests, writing them as functional tests using the high-level API of Mink makes sense IMO