Possible Race Condition in stdlib tests if using t.Parallel()

As mentioned above, Go 1.5+ now executes all tests concurrently since `GOMAXPROCS` is set to the number of cores on the machine and if you set the `t.Parallel()` flag.

This package was originally written with a global state to keep track of the current context being run synchronously.

I have not seen the race issue come up with about a dozen projects I use this package on testing on an 8 core (16 thread) machine, with the largest one using about 80 specs (tests). Nor I have received reports from others I have asked to test it. But it is coded in such a way that it could cause an issue with tests running concurrently with the `t.Parallel()` flag set.

Therefore, a refactor is required to move the state up into each `Given()` instead of globally and to make use of channels where items must remain global (I frown on `mutex.Lock()`s everything).

It will most likely loosen the ability to track the `Feature` context with this change, and the output may be out of order. But if you are using the `t.Parallel()` flag, you are already accepting things to be out of order.

In the interim, I could slap a big ol' a mutex lock on the global context which would resolve the issue if it ever comes up. But, that would greatly slow things down and I would prefer to refactor around it as mentioned above.

See #4 for details.