Support capturing separate screen recording files specific to each test method when reusing a single instance of BrowserWebDriverContainer for multiple test methods

Starting a new instance of a browser for each browser test is costly. That's why Geb has a WebDriver instance caching mechanism which allows to save time by using a single instance of the driver and hence the browser across all of the tests. The browser state (cookies and web storage) is also managed to prevent it bleeding from one test to another.

BrowserWebDriverContainer comes with a very neat support for recording the screen of the driven browser. Unfortunately it seems to be implemented in a way which assumes that both the browser and vnc recording containers will only be used for a single test method and then discarded. In geb/issues#630 we've been discussing with @leonard84 that it would be good to make it easy to use the screen recording support provided by Testcontainers from Geb. To be able to achieve that we would need to make it possible to capture separate screen recordings for multiple tests using a single BrowserWebDriverContainer instance. I could probably come up with some hacks or workaround for this problem but I believe that in the interest of users who might be familiar with BrowserWebDriverContainer and myself who would need to then maintain such hack/workaround it's best if that's actually added to Testcontainers.

I would like to propose adding a mode to BrowserWebDriverContainer which would restart the vnc container every time afterTest() is called on it. I'm willing to work on a PR with the necessary changes but before I do I would like to ask if such a contribution has a chance of being accepted. I can see this being somewhat against the design philosophy of Testcontainers where GenericContainer implements org.junit.rules.TestRule in a way where the container is started prior to the statement (single test case or the whole class depending on the rule annotation used) being executed and stopped afterwards. Therefore I'm asking this question upfront to avoid wasting my time and effort if such a change is unlikely to be accepted.

Start by inspecting BrowserWebDriverContainer's screen-recording lifecycle and the afterTest() hook. Determine how the browser and VNC recording containers are currently reused, then assess the proposed mode that restarts the VNC container after each test. Done means separate screen-recording files can be captured for multiple test methods using one BrowserWebDriverContainer instance.