Remove obsolete scenarios from default test suite

Ignore scenarios tagged with `@replacement_available` when
executing `rake features` or `rake features_html`.

Allow scenarios to be progressively excluded as the corresponding
unit tests become available.
Add development test suite to default rake tasks

These specs document interfaces that are not public; making
them visible, however, should make the test suite refactoring
easier to follow.
Refactor extract method `integrate_with_devise_trackable!`

Add Devise trackable integration specs
Disable outperformed Cucumber scenarios...

... related to the Devise trackable integration

The unit tests which cover the integration with the Devise trackable
strategy are sufficient to prevent any regression while the Devise
trackable interface does not vary.

The (slow) Cucumber feature remains available and should be used
when updating the Devise dependency.
Disable outperformed Cucumber scenarios...

... related to the token authentication handler behaviour activation.

The new 'token authentication handler' interface (and the corresponding
module) makes straightforward to unit test that the controllers do not
require authentication (behave as token auth. handlers) before asked to
do so.
Disable outperformed Cucumber scenarios...

... related to the `sign_in_token` option

The specs tagged with `sign_in_token_option` match almost exactly
the original Cucumber feature.

Use: `rspec --tag sign_in_token_option` to run them in isolation.
Disable outperformed Cucumber scenarios...

... related to the `header_names` option
Spot bug in `header_names` option implementation

It appeared when writing the RSpec integration tests in replacement
of the slow Cucumber scenarios.

Faster specs allow for a better coverage; the benefits of refactoring
the test suite for performance are showing up early :)

See #120
Mark bug specs as pending, disable outperformed scenarios...

... related with the `header_names` option

An issue was opened to keep track of the bug, see
https://github.com/gonzalo-bulnes/simple_token_authentication/issues/120

The specs do in fact provide a better coverage of the `header_names`
behaviour than the Cucumber scenarios did.
Minor refactor authentication handlers specs

Minor fix misspelling in the config. option interface spec
Disable outperformed Cucumber scenarios...

... relative to the `fallback_to_devise` option

The specs do cover totally the behaviour described by the Cucumber
scenarios. Additionally, they describe how the token authentication
handler behaves when the option is omitted.
Refactor simplify `define_token_authentication_helpers_for`

Remove the need for the `get_entity` helper method, make
easier to use variables in the methods definitions.
Minor refactor move fallback default to configuration

The default value of the `fallback_to_devise` remains static, but
it is now stored among the other configuration options.
Refactor use `:fallback` option instead of `:fallback_to_devise`

The change is internal and does not affect how the gem behaves.

Strictly speaking, the `:fallback` option can now be used from
`handle_token_authentication_for` in place of `:fallback_to_devise`;
however, since it is still undocumented, there is no reason to
notice the extension and the gem behaviour can be considered unchanged.
Refactor inject fallback auth. handler in helpers definition

Remove the responsibility of defining the fallback authentication
handler from the `define_token_authentication_helpers_for` method.
Fix memoization implementation error in class methods

The bug didn't modify the public behaviour of the gem,
but did create bunches of instances of EntityManager and
FallbackAuthenticationHandler without necessity. Anyway,
the code didn't do was it was intended to.

I should have written those tests back in:
55d34d4d5c0bf977b51b853aaa73307dcd40413a
Refactor remove unused methods
Disable outperformed Cucumber scenario...

... related to the `sign_in_token` option default value.

See spec/lib/.../configuration_spec.rb:65
Disable outperformed Cucumber scenario...

... related to setting configuration options from an initializer

Variables which behave as configuration  options can _sensu stricto_
always be modified from an initializer file. However, since most
files are required *before* the initializer files are read,
that ability is only effective when the variables are used at runtime.

The specs go a bit further than the scenarios, since not only
the `sign_in_token` option usage is tested, but also the usage of
the `header_names` option.

Both spec examples have in common a is very verbose setup; yet most
of what makes them interesting is that they cover a large part of the
authentication process, reducing the probablity of missing a call to
obsolete configuratio settings. There may be a better way to test that,
pointers are welcome!
Disable outperformed Cucumber scenarios...

... related to allowing several models to authenticate in one controller