SlugGenerator#conflicts? is too pessimistic

Hi,

I've run into the following behaviour while trying to regenerate slugs in friendly_id 4.0.8. Let's say I've got the following:

```ruby
class User
  friendly_id :name, :use => :slugged
end
```

and at the console I do

```ruby
> User.create(:name => "geoff")
=> #<User id: 1 name: "geoff", slug: "geoff">
> User.create(:name => "geoff")
=> #<User id: 2 name: "geoff", slug: "geoff--2">
```

So far, so good. Now I want to regenerate the slugs for all the Geoffs:

```ruby
> User.where(:name => "geoff").find_each do |u|
*   u.slug = nil
*   u.save
* end
=> nil
> User.where(:name => "geoff").map(&:slug)
=> ["geoff--3", "geoff--4"]
```

When User#1 had its slug regenerated, despite there being no other user with the slug "geoff", because User#2 had the slug "geoff--2", the generator assumed there was a conflict, and moved on to "geoff--3". This then repeats for User#2.

Basically this means there's no way to regenerate the slugs for a table without clearing them all first. Would you be interested in a patch that made the generator behave as follows:

1. If no other record with slug `normalized` exists, use `normalized`
2. If another user with slug `normalized` exists, then use `"#{normalized}#{separator}#{next_in_sequence}"`, where `next_in_sequence` is the lowest number not taken by another record.

I *think* this seems right, but I could be holding this thing completely wrong, so any thoughts you have before I start work on a PR would be very gratefully received. :)

Cheers,
Simon