Dominic: expose current (gherkin) scenario to step definition code via T...

I am using Cucumber to define tests for a system which calls out to a stub server that services HTTP requests:

Cucumber -[executes]-> step definition -[calls]-> system under test -[calls]-> stub server

The stub server works by recording and replaying a transcript of requests and responses, identified as belonging to a named scenario. Each Cucumber scenario corresponds to a scenario on the stub server, which is configured at execution-time with the expected sequence of requests and responses. In order to facilitate tracing and debugging between Cucumber, the system under test and the stub server, it is useful if the stub server's scenario can be matched by name to the Cucumber scenario which drives the behaviour that results in the stubbed HTTP calls.

As things stand, Cucumber-JVM does not provide access to a scenario's name or other details for code running within a step definition. This is by design, to prevent unwanted coupling (step definitions should be re-usable across scenarios, and indifferent to the particular scenario they are running in). However, in the use case described above, the step definition does not *behave* differently based on the scenario name; it merely passes the scenario name on to the stub server when recording its transcript of requests and responses. This does not result in any unwanted coupling, but makes it easier to trace calls across the system.

The change in this pull request exposes the currently-executing scenario's Gherkin Scenario object, via a ThreadLocal, so that a step definition can call CurrentScenario.get().getName() to discover the name of the currently-executing scenario.