Fixes Rails 7.1 raise_on_assign_to_attr_readonly

[professor]

Fixes #1467

Check the following boxes:

• Wrote good commit messages.
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Added an entry to the Changelog if the new
  code introduces user-observable changes.
• The PR relates to only one subject with a clear title
  and description in grammatically correct, complete sentences.

I manually tested this PR with these commands:

DB=sqlite  bundle exec appraisal rails-7.1 rspec /Users/todd.sedano/workspace/paper_trail/spec/models/wotsit_spec.rb
DB=sqlite  bundle exec appraisal rails-7.0 rspec /Users/todd.sedano/workspace/paper_trail/spec/models/wotsit_spec.rb
DB=sqlite  bundle exec appraisal rails-6.1 rspec /Users/todd.sedano/workspace/paper_trail/spec/models/wotsit_spec.rb

[ngan]

I think this is pretty dangerous since it silently throws away assignments of readonly attributes without the developer knowing about it. This is the exact problem that config.active_record.raise_on_assign_to_attr_readonly was looking to address.

I see some viable options:

1. We consider paper_trail's reify operation as a "dangerous" operation that automatically disable attr_readonly declarations (somehow) and forces the attributes to be rewritten.
2. We take the stance you can't have both worlds. As in, you can't reify a record if it's going to set a readonly attribute. This is basically not changing anything.
3. We only set the value iff it's a different value. This allows the reify to work in some cases and fail (loudly) in others. This seems a little odd to me, but still, it's an option.