Failing tests for slug regeneration behaviour

Modify slug regeneration test so that record should not have to be saved
twice for its slug to be regenerated, and added failing tests for the
expected behaviour of #should_generate_new_friendly_id?
Simplify #should_generate_new_friendly_id? logic

The #should_generate_new_friendly_id? predicate, called as part of the
before_validation callback #set_slug, accesses the current_friendly_id
attribute. However this is only set in a before_save callback, meaning
it is only present if a held instance of a model has previously been
saved.

The predicate's comments indicated that it checked both this value and
the current slug column's value against a regenerated slug base, to see
if a new slug was needed. However it only checked one -
current_friendly_id if set, otherwise the current slug column value.

Fixing both of the above demonstrated that current_friendly_id was in
fact not needed, however, as when forced to be set before #set_slug was
called, it was always identical to the current slug column.

This commit removes current_friendly_id completely, and simplifies the
predicate's check to compare the slug base with only the existing slug
column value.

All tests pass except one in SimpleI18n, which appears to rely on the
earlier behaviour. This will be addressed in the next commit.
Merge pull request #334 from urbanautomaton/fix-slug-regeneration-behaviour

Fix slug regeneration behaviour