initializer modifies class

Nobody has claimed this yet.

I'm a bit worried about
```ruby
def initialize(api, json_or_hash)
@api = api

raw_hash = json_or_hash.kind_of?(Hash) ? json_or_hash : JSON.parse(json_or_hash)
self.class.send(:id_attr, *raw_hash['related'].keys) if raw_hash.key?('related')

super(raw_hash)
end
```
in [base_model](https://github.com/ansible/ansible_tower_client_ruby/blob/master/lib/ansible_tower_client/base_model.rb#L39
) introduced in https://github.com/ansible/ansible_tower_client_ruby/pull/17

Not only does it modify a class whenever an instance is created, which can lead to different behaviour across different instances. It's also not thread safe, potentially leading to data corruption.

I'm also seeing inconsistent behaviour when accessing these `_id` methods

```ruby
(byebug) ap i.class
AnsibleTowerClient::JobTemplate < AnsibleTowerClient::BaseModel
(byebug) ap i.to_hash['related']
{
"created_by" => "/api/v1/users/1/",
"modified_by" => "/api/v1/users/1/",
"labels" => "/api/v1/job_templates/76/labels/",
"inventory" => "/api/v1/inventories/6/",
"project" => "/api/v1/projects/40/",
"credential" => "/api/v1/credentials/6/",
"notification_templates_error" => "/api/v1/job_templates/76/notification_templates_error/",
"notification_templates_success" => "/api/v1/job_templates/76/notification_templates_success/",
"jobs" => "/api/v1/job_templates/76/jobs/",
"object_roles" => "/api/v1/job_templates/76/object_roles/",
"notification_templates_any" => "/api/v1/job_templates/76/notification_templates_any/",
"access_list" => "/api/v1/job_templates/76/access_list/",
"launch" => "/api/v1/job_templates/76/launch/",
"schedules" => "/api/v1/job_templates/76/schedules/",
"activity_stream" => "/api/v1/job_templates/76/activity_stream/",
"survey_spec" => "/api/v1/job_templates/76/survey_spec/"
}
(byebug) ap i.cloud_credential
nil
(byebug) ap i.cloud_credential_id
nil
(byebug) ap i.credential
*** NoMethodError Exception: undefined method `credential' for #
Did you mean? credential_id

nil
(byebug) ap i.credential_id
6
```

TBH, I would favour no magic id columns and stick as close to the response as possible

Start in lib/ansible_tower_client/base_model.rb at BaseModel#initialize and inspect the id_attr call introduced by the referenced change. Reproduce the related-field examples from the issue and trace how class state affects separate instances and their _id accessors. Done means the behavior is consistent across instances without unsafe class mutation, with the intended response mapping documented by the resulting tests or behavior.

Written by the indexing model from the issue text.