Add back context to manage state

[sagikazarmark]

Is your feature request related to a problem? Please describe.
In the latest master the feature context has been replaced with Go's context package.

Additionally, since Go's context is immutable, step functions can now return a context, indicating they added something to it.

Personally, I'm not a fond of this new context pattern and I think it's not really a good use case for Go's context. Originally, Go's context is for carrying information between API layers, ie. something that you don't want to add to the API, but could be valuable information about a request, like correlation ID, authenticated user, etc.

The new context would require writing a lot of boilerplate code for adding/retrieving values to/from the context which would bloat the step functions.

Describe the solution you'd like
I'd like to see some sort of feature context added back, similar to what we had before.

Values passed between test steps are actually within a single API, and there is no "request scope" here, although one could argue that there are similarities between a scenario and a request.

Describe alternatives you've considered
An alternative is implementing step functions as members of a struct and storing state in there.

This is what I've been doing in godog and other frameworks, but I actually got to liking the previous context concept.

We could look around to see how other frameworks manage their context.

Additional context
This is a followup issue for #55 and #52. Both of them describe use cases which would require something like context was before.

[bkielbasa]

Based on the discussion in #50 I think we can go for it :)

There are a few decisions to make:

• should it be called context?
• should it behave the same way it used to?

Of course, it won't contain information about the step's parameters because we already have it.

BTW thanks for your contribution :)

[sagikazarmark]

I think it is commonly called context or feature context in other BDD libraries.

As for how it should look like: I'd say we should experiment. #52 and #55 both came from experimentation. I tried writing steps for my test cases and faced those issues.