[10.x] hash improvements

[timacdonald]

This will break:

• Existing applications that are using a hard coded hash. The fix for apps is seen in [10.x] Update fixture hash to match testing cost laravel#6259.
• Applications that are manually duplicating user records and re-setting their password. If they are using $model->replicate() it won't be an issue.

Aside from that I don't see concrete examples that a new value is passing through the setter where you expect it not to be using the current algorithm. No doubt there will be edge cases out there.

[valorin]

@timacdonald check out the PR by @bastien-phi at bastien-phi#1

Rejecting hashes that don't exactly match in the Hash cast has the potential to break things. We don't think it's safe to assume the hash will always exactly match the configuration, but should be more flexible. If you're in the middle of a password upgrade, you may have the situation where some hashes are still on an older configuration because the user hasn't logged in with their password yet.

I think it'd be ok for a major version (i.e. 11.x) - the dev would have to update code to factor it in and not needless pass around the hash, plus generate for testing rounds, but probably not for 10.x.