Freezable triggers on external objects when using fibers

Because `thread_mattr_accessor` uses `Thread.current[]`, doing `self.prevent_instance_data_manipulation_after_freezing = false` in the `Object` extension doesn't work when using fibers (it defaults to `true`). FWIW discussions in https://github.com/rails/rails/issues/19693 seem related.

In our case we set `config.active_support.isolation_level = :fiber` in the Rails config.

For instance:
```
/usr/local/bundle/gems/console1984-0.1.31/lib/console1984/freezeable.rb:42:in `block in prevent_sensitive_method': You can't invoke instance_variable_get on # (Console1984::Errors::ForbiddenCommandAttempted)
from /usr/local/bundle/bundler/gems/activerecord-jsonb-associations-dde23b72bdb7/lib/activerecord/jsonb/associations/association_scope.rb:7:in `last_chain_scope'
from /usr/local/bundle/gems/activerecord-7.1.3/lib/active_record/associations/association_scope.rb:125:in `add_constraints'
from /usr/local/bundle/gems/activerecord-7.1.3/lib/active_record/associations/association_scope.rb:29:in `scope'
```

Any reason to use `thread_mattr_accessor` in this case versus `mattr_accessor`?

Start with the Object extension where prevent_instance_data_manipulation_after_freezing is set and trace how thread_mattr_accessor behaves when Rails uses config.active_support.isolation_level = :fiber. Compare the behavior with the related Rails discussion in issue #19693 and reproduce the external-object failure shown in the stack trace. Done means the setting has defined behavior under fiber isolation and the reported console operation no longer fails unexpectedly.

Written by the indexing model from the issue text.